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内 容 提 要 


本 书 重 在 介绍 Oracle 数据 库 的 性 能 调 优 方法 及 相应 的 工作 思路 ， 但 并 不 拘泥 于 技术 细节 。 作 者 结合 多 
年 的 丰富 经 验 , 借助 大 量 真 实 案例 剖析 了 相关 技术 原理 , 阐述 了 理论 知识 在 实践 中 的 应 用 方法 , 并 总 结 出 “ 思 


路 是 道 ， 


操作 方法 是 技 。 得 道 是 极 大 的 提升 ， 也 是 DBA 的 思想 精髓 ”的 精 腑 论断 。 


全 书 分 为 三 个 部 分 ， 共 19 章 。 第 一 部 分 介绍 了 Oracle 的 基本 原理 ， 以 及 从 基本 原理 衍生 而 出 的 一 些 
分 析 问 题 的 方法 和 思路 。 第 二 部 分 介绍 了 DBA 应 该 掌握 的 常用 工具 。 第 三 部 分 介绍 了 DBA 分 析 问 题 的 主 
要 思路 和 一 些 典型 案例 。 
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与 在 前 言 之 前 的 话 


按理 说 前 言 之 前 就 不 应 该 说 什么 了 。 不 过 这 几 天 我 真 的 有 一 种 不 吐 不 快 的 感觉 如 果 不 马 上 


把 这 些 东 西 写 出 来 和 大 家 共享 ， ж 
京 大 学 的 110 周年 庆典 ， 也 是 我 1 


一 次 同学 聚会 。 遇 到 这 种 
校友 的 聚会 ， 当 然 会 有 所 不 同 了 。 我 们 安排 了 一 个 活动 , 请 当年 最 英俊 潇洒 、 才 华 横 溢 的 陈 道 蓄 


EMA BAF 


ЕКЙ, 


本 以 为 这 就 是 一 次 活 
中 学 生 和 谤 贝尔 奖 获 得 者 面对面 活动 ”中 的 一 个 环 攻 ， 安 排 我 人 


好 像 会 对 读者 有 所 愧 次 似 的 。 今 年 5 月 20 号 是 老 白 的 母校 南 


门 南大 计算 机 系 88 级 同学 毕业 20 周年 ， 于 是 有 好 事 之 徒 组 织 


XD 


让 我 们 回味 一 下 20 年 前 当 学 生 的 感觉 。 


下 、 大 块 吃 肉 的 好 事 ,， 老 白 自 然 是 积极 响应 的 。 不 过 既然 是 南大 


动 而 已 ， 并 没有 十 分 认真 。 没 想到 这 个 活动 最 终 成 为 “全 国 60 名 优秀 


门 和 来 自 全 国 的 60 名 优秀 中 学 生 


一 起 聆听 陈 道 蓄 教 授 的 讲座 。 而 陈 道 蓄 教 授 也 一 如 20 年 前 的 严谨 ,为 我 们 精心 准备 了 一 次 30 分 


入 软件 工程 中 的 核心 问题 ,让 人 


钟 的 讲座 , 题目 是 《软件 工程 中 的 “ 软 实 力 ”》 这 个 和 软件 工程 有 关 的 讲座 ， 以 几 幅 世界 名 画 导 
回味 无 穷 。 更 令 我 感到 惊喜 的 是 陈 老师 关于 “ 道 ” 的 感悟 ， 他 对 


TIBI EAGER, 让 我 有 一 种 醒 醒 灌顶 的 感觉 。 由 于 音响 调试 得 不 好 , 坐 在 后 排 的 我 只 能 支 棱 着 


耳 打 ,认真 地 听 他 所 讲述 


的 每 一 个 字 ， 直 到 全 场 响起 热烈 的 掌声 ， 我 才 从 沉醉 之 中 醒 来 。 我 想 ， 


这 30 分 钟 ,足以 让 我 受益 10 年 。 而 陈 老师 关于 道 的 感悟 ， 正 和 老 白 这 本 书 的 宗旨 契合 ,悟道 是 
“Thinking in Oracle” 的 最 高 境界 。 


陈 老 师 谈 到 做 一 件 事 ， 
只 能 靠 自 己 感悟 ; 顺 是 有 形 的 东西 ， 很 容易 获得 ， 


总 是 会 磁 到 “ 道 ” 和 “ 需 "。 道 是 形 而 上 的 东西 ， 是 别人 无 法 教授 的 ， 
也 最 容易 使 人 从 中 受益 。 由 于 悟道 艰难 ， 因 此 


大 多 数 人 都 会 追求 顺和 而 放弃 悟道 。 不 过 道 终究 是 形 而 上 的 东西 ， 一旦 悟道 , 那么 器 就 显得 那么 渺 


小 了 。 


对 于 DBA 也 是 如 此 ,很 多 朋友 整 天 都 在 追求 某 个 独家 秘籍 ， 比 如 一 个 内 部 才 有 ( Internal 


ONLY ) 的 文档 ,或 者 一 个 
耐烦 。 前 些 天 ,公司 的 


却 本 、 工 具 ， 而 如 果 你 让 他 去 认真 读 读 Oracle Concepts， 他 就 会 很 不 
个 小 伙 子 要 推荐 一 个 工具 给 老 储 ,， 看 老 储 没什么 反应 ,就 着 急 地 跑 过 去 


和 他 解释 这 是 个 什么 东西 。 老 储 也 是 个 很 直 白 的 人 ,他 说 一 般 我 们 会 根据 原理 来 分 析 该 如 何 处 理 ， 
青 去 查看 资料 ,看 看 具体 的 命令 ,平时 没 必 要 去 记 这 些 东西 。 我 觉得 老 储 这 话说 得 很 好 ， 由 道 御 
需 是 再 顺理成章 不 过 的 事情 了 。 一 旦 你 能 够 入 道 了 , 那么 “ 形 而 下 ”的 东西 就 太 好 办 了 。 可 能 我 
并 不 知道 某 个 著名 的 脚本 , 但 是 一 旦 我 人 了 道 , 那么 要 做 类 似 的 分 析 , 就 很 容易 写 出 类 似 的 脚本 。 
而 如 果 你 并 未 掌握 这 个 问题 的 相关 原理 , 那么 哪怕 你 拿 着 无 数 精妙 的 脚本 , 也 可 能 分 析 不 出 什么 


东西 。 


IV 写 在 前 言 之 前 的 话 


很 多 DBA 在 学 习 过 程 中 ,总 是 会 不 断 地 追求 些 解决 问题 的 具体 办 法 ， 一 本 好 书 、 一 个 脚本 、 
一 套 工具 软件 ， 都 会 让 我 们 感到 兴奋 。 而 实际 上 ， 这 些 都 属于 “器 ”的 范畴 ， 如 果 把 它们 作为 我 
们 悟道 路 上 的 一 些 工具 和 手段 , 那么 是 无 可 厚 非 的 , 不 过 你 如 果 把 追求 这 些 当成 自己 追求 的 终极 
目标 , 那 就 舍 本 逐 末了 。 我 们 不 应 该 花 太 多 的 精力 去 追求 这 些 东西 ,而 应 该 把 更 多 时 间 用 在 感悟 
Oracle 本 身 的 “ 道 ” 上 。 公 司 的 一 个 同事 总 是 会 发 给 我 一 些 新 奇 的 脚本 或 者 一 些 不 错 的 书籍 ， 不 
过 我 一 般 都 会 拒绝 。 我 会 告诉 他 ， 你 如 果 有 时 间 就 认真 阅读 一 下 , 我 没有 时 间 看 这 些 东 西 。 这 些 
脚本 或 者 书籍 都 是 很 不 错 的 ， 如 果 是 10 年 前 ， 我 会 很 有 兴趣 认真 地 阅读 。 而 现在 ， 我 最 需要 认 
真 阅读 的 是 Oracle 的 官方 文档 ， 从 那里 ， 我 能 够 了 解 到 最 原 汁 原味 的 东西 ， 从 中 感悟 到 更 多 的 
Oracle 的 本 质 。 以 我 的 理解 ,你 如 果 已 经 掌握 了 某 种 方法 , 那么 类 似 的 方法 哪怕 有 几 十 个 上 百 个 ， 
大 多 数 对 你 来 说 也 是 没有 多 大 价值 的 了 。 如 果 你 已 经 习惯 于 用 某 种 工具 去 完成 一 个 工作 , 那么 其 
他 的 工具 对 你 来 说 再 好 也 是 多 余 的 。 如 果 你 总 是 在 不 停 地 学 习 一 些 新 的 工具 ,一 些 似是而非 的 新 
东西 ， 而 你 就 可 能 没有 足够 的 时 间 去 独立 地 思考 和 感悟 。 

因此 ， 在 DBA 成 长 的 过 程 中 ， 除 了 如 饥 似 渴 地 阅读 ， 认 真 地 参与 实践 之 外 ， 多 花 些 时 间 来 
思考 一 些 形 而 上 的 东西 , 对 于 突破 瓶颈 , 尽快 “人 道 " 是 很 有 帮助 的 。 当 你 要 去 安装 一 套 11g RAC 
的 时 候 , 你 会 怎么 做 呢 ? 是 马上 去 网 上 搜索 一 个 攻略 呢 , 还 是 认真 阅读 一 遍 Oracle 官方 的 安装 指 
南 呢 ? 我 想 绝 大 多 数 DBA 会 选择 前 者 。 根 据 攻略 ， 你 可 以 十 分 快 地 完成 安装 工作 ， 而 如 果 要 去 
阅读 安装 指南 ， 可 能 要 花 上 一 两 天 来 认真 思考 和 体会 。 这 两 者 的 效果 区 别 是 十 分 明显 的 ， 一 个 是 
别人 悟 出 来 的 东西 ， 你 直接 就 可 以 拿 来 使 用 ， 很 快 ， 不 用 费心 思 ; 另外 一 条 路 是 你 自己 去 感悟 一 
些 东西 ， 去 解决 一 些 问题 ,因此 可 能 要 花费 更 多 的 时 间 和 脑力 。 不 过 ,如果 你 真 的 通过 认真 阅读 
安装 手册 ， 经 过 多 次 实践 ， 充 分 掌握 了 安装 中 的 一 些 过程 ， 那 么 你 今后 再 做 Lg RAC 安装 的 时 


能 再 去 谷歌 或 者 别处 打听 了 。 

去 年 ， 一 个 网 友 打 电话 给 我 ， 咨 询 一 个 11.2.0.2 GRID 的 安装 问题 ， 我 们 排除 了 那个 著名 的 
思科 交换 机 问题 后 ， 这 个 问题 还 是 没有 解决 ， 后 来 我 建议 他 跟踪 一 下 rootsh 这 个 脚本 ， 搞 清楚 
到 底 在 什么 地 方 有 问题 。 最 后 这 个 问题 终于 找到 了 , 是 由 于 网 卡 不 稳定 导致 的 。 不 过 通过 这 次 安 
装 ， 他 彻底 地 分 析 了 rootsh 中 的 每 个 步 又 的 细节 ， 他 觉得 今后 再 碰 到 rootsh 出 现 的 问题 ， 就 十 
分 有 信心 了 。 

在 学 习 过 程 中 , 不 要 过 于 依赖 快餐 式 的 攻略 , 多 静 下 心 来 , 认真 思考 和 感悟 一 下 Oracle 的 本 
Wi, 对 每 个 DBA 来 说 都 是 十 分 有 意义 和 有 价值 的 。 只 有 通过 御 器 ， 从 而 入道， 才 是 最 佳 的 路 径 。 
这 是 陈 老 师 的 讲座 给 我 的 启示 ， 我 也 希望 我 对 此 的 感悟 能 够 传递 给 每 个 读者 。 


白 鳝 
2012 年 5 月 19 日 于 南京 


了 中 


前 


写 完 《Oracle 优化 日 记 : 一 个 金牌 DBA 的 故事 》 和 《ORACLERAC 日 记 》 后 ， 很 多 网 友 问 
我 下 面 是 否 会 继续 写 书 。 我 的 想法 还 是 和 以 前 一 样 ， 先 整理 整理 自己 的 思路 ， 写 一 些 东 西 发 在 
Oracle 粉丝 网 上 ， 写 过 一 段 时 间 再 根据 已 经 完成 的 内 容 决定 新 书 的 结构 。 开 始 我 是 想 把 新 书写 成 
DBA 日 记 系 列 第 三 部 的 ， 不 过 写作 的 过 程 中 才 发 现 这 种 模式 写 下 去 有 一 点 千篇一律 的 感觉 
很 多 案例 从 根本 上 看 十 分 相似 。 有 一 次 和 同事 老 储 聊天 的 时 候 , 他 提 到 现在 很 多 年 轻 人 不 会 按照 
Oracle 的 内 在 原理 去 考虑 问题 ， 从 而 导致 经 常 出 现 常识 性 的 错误 。 他 的 这 句 话 就 像 火花 一 样 在 我 
脑海 中 闪现 ，Thinking in Oracle 这 几 个 英文 词汇 就 出 现在 我 的 脑 中 。 如 果 每 个 人 都 能 以 Oracle 的 
基本 原理 为 依据 去 考虑 问题 , 那 不 是 很 好 吗 ? 老 储 的 英文 名 字 是 John ,在 我 的 朋友 里 有 两 个 Johns 
一 个 是 老外 John ， 我 还 在 玩 ICQ 的 时 候 认 识 的 网 友 ， 一 个 Oracle 技术 狂人 。 不 过 老外 John 现在 
已 经 成 为 一 家 银行 的 IT 技术 主管 ， 随 着 岁月 的 流逝 ， 当 年 的 技术 狂人 现在 已 经 成 了 狂热 的 人 文 
主义 者 。 去 年 圣诞 新 年 假期 他 刚刚 完成 了 10000 公里 行程 的 中 南美 洲 自 驾 游 , 所 到 之 处 全 部 人 住 
当地 最 高 级 的 酒店 ， 吃 当地 最 昂贵 的 美食 ,还 常常 贸 逅 美女 ,虽然 邮件 还 只 是 寥寥 数字 , 但 是 羔 
莫 嫉 妨 候 已 经 让 我 把 这 个 资本 主义 的 老家 伙 好 好 咏 了 几 天 。 男 外 一 个 John SEE, flm T RE 
在 我 对 面 的 弟兄 ， 我 大 学 时 的 室友 。 自 从 1995 年 我 把 他 从 unixware 汉化 小 组 忽 修 到 深圳 后 ， 我 
们 一 直 在 一 起 合作 。 老 储 是 个 很 低调 的 人 , 低调 到 第 一 次 和 客户 打交道 的 时 候 客 户 可 能 会 质疑 他 
的 能 力 ， 不 过 随 着 和 他 交往 的 深入 ， 你 可 以 发 现 他 的 深 不 可 测 。 

老 储 的 建议 让 我 重新 定义 了 本 书 的 结构 ， 把 它 分 为 基础 知识 、 工 具 、 方 法 和 案例 四 大 部 分 。 
不 过 随 着 写作 的 深入 ,我 发 现 这 个 工作 是 十 分 艰巨 的 。 这 样 一 本 书 结 构 之 大 ， 内 容 之 庞杂 ， 远 远 
超出 了 我 的 想象 。 于 是 我 重新 调整 结构 ,将 工具 这 一 部 分 的 内 容 从 书 中 拿 掉 ,准备 独立 成 书 , 把 
方法 和 案例 用 两 章 讲 完 。 这 样 调整 后 本 书 的 内 容 更 为 紧凑 ， 篇 幅 也 可 以 控制 在 450 页 左右 。 

更 大 的 惊喜 也 接 中 而 来 , 我 终于 说 服 了 老 储 ， 让 他 参与 到 本 书 的 写作 中 来 。 其 实 第 一 次 和 老 
储 沟通 这 本 书 的 时 候 我 就 邀请 过 他 , 不 过 被 他 以 没 空 为 由 拒绝 了 。 老 储 是 一 个 懒散 的 人 , 我 每 次 
给 他 布置 写 文档 的 任务 , 他 总 是 在 快 到 期 的 时 候 才 开始 动手 , 不 过 每 次 提交 的 东西 都 让 人 无 可 挑 
剔 。 能 让 这 么 靠 谱 的 人 参与 本 书 的 写作 ， 确 实 可 以 为 书 增色 不 少 。 老 储 赁 着 深厚 的 开发 功力 , 在 
性 能 优化 方面 具有 很 敏锐 的 观察 力 , 往往 能 够 在 很 短 很 短 的 时 间 内 找到 系统 的 关键 问题 ,而 且 他 
在 Oracle 文件 结构 和 ASM 的 结构 方面 的 研究 很 深 ， 自己 也 编写 了 一 个 类 似 DUL 的 工具 。 有 了 
他 的 加 入 ， 关 于 ASM 原理 和 数据 文件 结构 这 部 分 内 容 我 就 可 以 推 给 他 了 。 此 前 我 正 为 这 两 节 犯 
Tk, 考虑 是 否 在 书 中 去 掉 这 两 节 ， 补充 一 些 其 他 内 容 。 老 储 的 加 入 使 这 两 节 保 留 了 下 来 ， 对 于 数 
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据 文 件 结构 和 ASM 文件 结构 感 兴趣 的 朋友 可 能 会 感到 庆幸 ， 保 留 这 两 节 也 使 得 本 书 的 内 容 更 加 


我 给 本 书 起 的 名 字 是 《Thinking in ORACLE 之 DBA 的 思想 天 空 》 主编 觉得 这 是 一 个 十 分 
霸气 的 名 字 。 实 际 上 ， 透 过 某 个 事物 的 本 质 去 看 问题 ,无 论 针对 什么 ， 都 是 比较 高 的 境界 。 对 于 
某 些 事 情 , 在 没有 和 弄 清 楚 其 本 质 之 前 , 我 们 往往 难以 找到 正确 的 应 对 方法 , 虽然 偶尔 我 们 会 像 频 
猫 磁 到 死 耗 子 一 样 牌 打 正 着 ， 但 是 好 运气 不 会 总 是 伴随 着 你 。 就 像 前 些 年 ， 我 不 了 解 “ 回 南天 ” 
的 成 因 ， 因 此 在 每 年 的 2、3 月 份 总 是 十 分 痛苦 。 在 广东 沿海 生活 过 的 人 都 知道 每 年 的 春天 总 是 
会 碰 到 回 南天 ， 时 间 有 长 有 短 ， 至 少 也 在 半 个 月 左右 。 在 回 南天 里 ， 家 里 到 处 都 是 湿 渡 渡 的 ， 地 
上 、 墙 上 甚至 天 花 板 上 都 会 渗 出 水 珠 。 在 这 样 的 环境 中 生活 半 个 月 ,绝对 是 十 分 恐怖 的 事情 。 为 
了 让 家 里 尽快 干 起 来 , 我 的 第 一 反应 是 门窗 大 开 ， 同 时 用 风扇 拼命 扇 风 。 不 过 这 样 处 理 并 不 能 减 
轻 返 水 的 现象 ,有 时 候 反而 水 更 加 多 了 。 后 来 我 请 教 了 一 位 搞 大 气 海洋 研究 的 人 ,他 告诉 我 回 南 
天 的 成 因 是 春天 东南 季风 带 来 大 量 的 水 气 ， 而 当 气温 回升 的 时 候 ， 室 外 气温 高 于 室内 气温 ,湿热 
的 空气 遇 到 室内 较 冷 的 物体 时 ， 就 会 发 生冷 凝 现 象 , 从 而 就 引发 了 反 水 的 现象 。 一 旦 了 解 了 回 南 
天 的 成 因 ， 就 很 容易 找到 对 付 回 南天 的 办 法 了 ， 只 要 碰 到 气温 大 幅度 回升 的 天 气 ， 就 门窗 紧 闭 。 
靠 着 这 个 办 法 ,我 终于 摆脱 了 回 南天 的 困扰 , 无 论 门 外 的 走廊 湿 成 什么 样 ， 我 家 的 地 上 总 是 干 干 
的 。 后 来 每 当 我 看 到 朋友 家 里 满 地 积 水 的 时 候 ， 就 会 把 这 个 方法 教 给 他 们 ,他们 也 逐渐 远离 了 回 
南天 的 困扰 。 

从 这 个 生活 案例 中 , 我 们 也 可 以 看 到 , 一 旦 了 解 了 问题 的 本 质 ， 就 很 容易 找到 正确 的 解决 方 
法 。 而 没有 理解 问题 本 质 的 时 候 ， 我 们 所 采取 的 应 对 措施 不 一 定 是 靠 谱 的 。 

这 个 原则 应 用 到 Oracle 数据 库 方面 ， 也 是 一 样 的 。 对 于 每 个 来 应 聘 DBA 的 人 我 都 会 问 他 们 
一 个 问题 : "Oracle 到 底 是 什么 ? ”有 些 人 会 用 数据 库 基 础 的 理论 来 回答 我 :“ 数 据 库 是 数据 的 集 
合 。” 也 有 些 人 会 感到 茫然 , 不 知道 我 问 这 个 问题 是 什么 意思 。 实 际 上 很 多 Oracle DBA 从 来 没有 
思考 过 这 个 问题 。“Oracle 就 是 Oracle， 是 一 个 产品 ， 还 能 有 什么 意思 呢 ? 我 不 知道 Oracle 到 底 
是 什么 也 没有 影响 到 我 做 一 个 合格 的 DBA。” 很 多 人 都 会 这 么 想 。 

实际 上 对 于 Oracle 我 们 确实 还 需要 重新 去 认识 认识 , 每 个 DBA 在 学 习 Oracle 的 时 候 都 往往 
注重 于 学 习 如 何 建 库 、 如 何 管理 、 如 何 编程 、 如 何 优化 。 我 们 总 在 不 停 地 去 学 习 一 些 方法 ,学 习 
一 些 秘 籍 。 如 果 偶 尔 学 到 了 一 些 不 传 之 秘 ， 都 会 感到 兴奋 异常 。 也 有 些 人 使 用 这 些 秘籍 解决 了 一 
些 疑 难 杂 症 ， 成 为 了 大 家 传说 中 的 高 手 。 

虽然 说 这 也 是 学 习 Oracle 数据 库 最 为 常见 的 一 种 方法 , 但 是 这 样 学 习 下 去 , 我 们 总 是 在 记忆 
一 些 枯燥 的 语法 和 脚本 , 虽然 经 过 数 年 我 们 积累 下 了 大 量 的 经 验 , 但 还 是 无 法 真正 地 理解 Oracle, 
数据 库 升 级 了 ， 系 统 变化 了 , 我 们 就 必须 从 头 去 学 习 。 常 年 累 月 , 我们 总 是 在 一 次 一 次 循环 往复 
地 重复 着 同样 的 事情 , 直到 筋疲力尽 ,对 Oracle 失去 往日 的 激情 ,最 终 РВА 只 是 一 个 职业 , Oracle 
只 是 我 们 谋生 的 手段 。 这 样 学 习 下 去 ， 几 年 后 ,很 多 人 就 会 碰 到 瓶颈 ， 虽 然 说 自己 处 理 问题 的 能 
力 和 工作 经 验 已 经 很 丰富 了 ， 但 是 技术 好 像 停 清 不 前 了 。 我 周围 一 些 做 了 五 六 年 DBA 工作 的 朋 
友 都 遇 到 过 类 似 的 情况 , 他 们 咨询 我 的 时 候 , 我 告诉 他 们 ,这 是 因为 经 验 的 积累 已 经 到 了 一 定 程 
HE, 需要 对 Oracle 基础 概念 有 更 深刻 的 认识 。 这 种 情况 下 , 你 需要 静 下 心 来 认真 看 书 , 学 习 Oracle 
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的 基础 概念 ， 只 有 彻底 搞 清楚 了 这 些 , 才能 跨 过 这 道 坎 ， 达 到 一 个 新 的 境界 。 绝 大 多 数 工作 了 五 
六 年 的 朋友 已 经 无 法 静 下 心 来 做 这 些 事情 了 , 因此 他 们 失去 了 突破 的 机 会 。 不 过 也 没关系 ,大 多 
数 人 选择 了 新 的 职业 规划 ， 从 事 管 理 ， 或 者 转向 售 前 、 业 务 专家 等 职位 。 

事实 上 , 我 们 可 以 换 一 种 方式 来 学 习 Oracle, ib Oracle 的 精神 融入 DBA 的 血液 中 , 让 DBA 
像 Oracle 一 样 思考 问题 ， 使 Oracle 成 为 我 们 的 爱好 ， 作 为 我 们 生命 的 一 部 分 存在 。 对 于 大 多 数 
DBA 来 说 , 这 也 许 只 是 一 个 乌托邦 式 的 理想 ， 多数 DBA 只 是 需要 有 一 份 工作 , 需要 靠 这 份 工 作 
KEF, RHET, 享受 生活 。 并 不 是 所 有 的 人 都 希望 让 Oracle 成 为 自己 生命 的 一 部 分 , 这 是 很 
现实 的 ， 不 过 我 们 虽然 可 以 仅仅 把 Oracle 当做 是 谋生 手段 ， 但 也 还 是 可 以 同时 尝试 了 解 Oracle 
更 多 的 本 质 ， 像 Oracle 一 样 思考 。 

对 大 多 数 人 而 言 , 像 Oracle 一 样 思 考 虽然 不 能 带 给 你 更 多 的 生活 乐趣 , 但 是 通过 以 这 样 的 方 
式 去 学 习 和 思考 ， 会 更 加 精确 地 了 解 Oracle 的 精髓 ， 让 自己 在 DBA 的 成 长 过 程 中 少 走 弯路 。10 
多 年 前 我 第 一 次 接触 Java 的 时 候 ， 感 到 十 分 头痛 。 不 是 自 夸 ，10 多 年 前 ， 我 是 一 个 相当 不 错 的 
C 程序 员 ， 最 高 纪录 是 一 天 之 内 编写 500 多 行 复杂 的 代码 ， 而 且 一 次 性 编译 通过 ， 一 次 性 测试 通 
il, 这 样 的 记录 的 诞生 是 基于 十 分 良好 的 过 程 思维 能 力 的 。 不 过 我 这 个 自封 的 编程 高 手 第 一 次 接 
Йй Java 的 时 候 ， 却 感到 十 分 吃力 。 我 无 法 用 面向 对 象 的 思想 去 编写 程序 ， 所 以 学 起 Java 来 十 分 
痛苦 ， 几 次 学 习 ， 最 后 都 放弃 了 。 直 到 有 一 天 我 看 到 了 一 本 英文 的 书籍 Thinking in Java， 通 过 这 
AB, 我 掌握 了 Java 和 面向 对 象 设计 、 编 程 的 主要 思路 。 自 从 看 了 这 本 书 之 后 , 我 再 次 面 对 Java 
程序 的 时 候 ， 发 现 一 切 都 是 那么 地 简单 ， 很 快 我 就 掌握 了 Java 编程 。 现 在 我 虽 仍 然 还 只 是 一 个 
三 流 的 Java 程序 员 ， 不 过 粉丝 网 的 一 些 修 修补 补 的 工作 我 完全 能 够 胜任 了 ， 而 且 在 和 一 些 Java 
开发 人 员 交 流 的 时 候 ， 我 也 能 够 很 快 地 理解 他 们 的 思路 。 

后 来 我 总 结 了 一 下 ， 在 看 Thinking in Java 这 本 书 之 前 ， 我 在 编写 Java 程序 的 时 候 ， 并 没有 
理解 面向 对 象 编程 的 概念 ， 只 能 是 照 猫 画 虎 ,， 拿 着 一 个 例子 在 上 面 修改 。 实 际 上 我 的 编程 风格 还 
是 面向 过 程 的 ， 因 此 写 出 来 的 代码 质量 很 差 。 而 通过 阅读 Thinking іп Java， 我 终于 学 会 了 面向 对 
象 的 方法 ， 用 Java 本 身 的 思想 去 考虑 问题 ， 因 此 能 够 更 加 准确 地 抓 住 问 题 的 本 质 。 我 想 ， 学 习 
Oracle 数据 库 也 是 这 样 , 如 果 我 们 通过 一 个 又 一 个 案例 去 学 习 Oracle , 那么 将 永远 停留 在 表层 上 。 
有 些 DBA 只 能 重复 相同 的 案例 , 这样 的 DBA, 哪怕 干 上 10 年 20 年 , 也 可 能 只 学 到 Oracle 的 一 
些 皮毛 ， 碰 到 一 个 没有 见 到 的 案例 ， 可 能 就 会 感到 手足 无 措 。 而 水 平 高 一 些 的 DBA 往往 能 够 判 
断 出 案例 的 相似 性 , 并 通过 分 析 找 到 类 似 案例 的 解决 方法 , 这 其 实 就 是 因为 透 过 现象 看 到 了 问题 
的 本 质 。 

很 多 DBA 可 能 都 碰 到 过 我 下 面 所 说 的 一 些 问 题 ， 有 时 候 我 们 无 法 评估 某 项 调整 可 能 对 系统 
带 来 的 影响 , 有 时 候 我 们 面 对 一 个 复杂 局 面 的 时 候 很 难 快速 找到 问题 的 关键 , 也 有 时 候 我 们 在 为 
解决 某 种 等 待 事件 而 感到 无 从 人 手 。 实 际 上 , 遇 到 这 些 问 题 , 都 是 因为 缺乏 对 于 Oracle 内 部 原理 
的 充分 认识 。 在 很 多 情况 下 ， 当 经 验 无 法 为 我 们 提供 足够 支持 的 时 候 ， 就 必须 从 原理 出 发 进行 思 
考 ， 才 有 可 能 真正 掌握 问题 的 根源 ， 从 而 解决 问题 。 

前 几 天 我 在 一 个 客户 现场 做 数据 拯救 工作 的 时 候 , 他 们 的 备 库 (也 就 是 现在 的 主 生产 库 ) Ж 
然 宕 机 了 ， 当 时 客户 正在 做 一 个 删除 临时 文件 的 操作 ,领导 就 认为 他 这 个 操作 导致 了 宕 机 ， 而 操 
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作 人 员 也 觉得 很 揭 枉 ,因为 这 是 一 个 十 分 常规 的 操作 。 我 看 了 看 日 志文 件 , 从 日 志 上 看 不 出 任何 
由 于 临时 表 空 间 和 临时 段 操 作 引 起 的 问题 , 同时 又 看 到 了 一 个 好 像 是 人 工 操作 停 库 的 信息 ,于 是 
推断 可 能 是 人 为 操作 所 致 。 后 来 经 过 多 方面 查证 ， 确 实 是 有 个 DBA 在 家 里 远程 做 维护 的 时 候 ， 
发 现 操作 HANG 住 了 ， 人 情急 之 下 ， 直 接 重 启 了 数据 库 。 如 果 你 不 了 解 临时 段 和 临时 表 空 间 操作 
的 原理 ， 面 对 这 个 问题 , 很 可 能 一 上 来 就 把 重点 放 在 删除 临时 文件 导致 宕 机 问题 的 分 析 上 面 , 这 
样 就 偏离 了 正确 的 方向 ， 解 决 问题 的 效率 和 成 功率 就 会 大 大 降低 。 

我 们 强调 理论 的 重要 性 , 也 不 是 片面 强调 理论 而 不 重视 实践 Oracle 数据 库 是 实践 性 很 强 的 ， 
没有 实践 ， 光 学 习 理 论 是 无 法 成 为 真正 的 高 手 的 。 比 如 说 我 们 学 习 了 很 多 OW! 相关 的 理论 ， 了 
解 了 数据 库 等 待 事件 和 一 些 状态 指标 的 含义 ,但 是 我 们 看 到 一 个 库 的 AWR 报告 的 时 候 ， 还 是 无 
法 知道 某 个 指标 是 否 正常 。 当 对 大 型 OLTP 系统 缺乏 实践 经 验 的 时 候 , 我 们 就 无 法 知道 大 型 OLTP 
系统 的 一 些 技术 指标 的 特性 ， 因 此 也 很 难 从 中 找到 疑点 ， 进 而 找到 解决 问题 的 方法 。 

这 些 年 里 我 接触 过 大 量 的 DBA, 我 一 般 把 他 们 分 为 四 大 类 。 第 一 类 DBA 是 经 验 型 的 ， 处理 
问题 的 主要 方式 取决 于 以 往 的 经 验 , 他 们 往往 都 有 很 好 的 习惯 , 会 把 每 一 个 处 理 过 的 案例 整理 出 
来 ,今后 再 碰 到 这 类 案例 的 时 候 ， 他 们 会 很 快 地 解决 问题 。 随 着 工作 时 间 的 增长 ， 他 们 的 技术 也 
会 相应 地 提高 。 第 二 类 DBA 是 理论 型 的 ,他 们 具有 很 深 的 理论 基础 ,经 常 探讨 一 些 “Oracle Internal 
Only” 的 高 深 问题 ， 比 如 他 们 能 够 很 清晰 地 告诉 你 共享 池 分 配 的 算法 ， 告 诉 你 checkpoint 的 工作 
原理 , 但 是 这 些 DBA 往往 缺乏 实际 的 工作 经 验 ， 他 们 研究 Oracle 却 很 少 有 机 会 接触 大 型 的 数据 
库 系 统 , 因此 实际 解决 问题 的 能 力 并 不 强 。 另 外 , 由 于 他 们 的 知识 比较 片面 , 在 某 些 方面 很 深入 ， 
而 某 些 方面 就 是 浅 尝 辑 止 ， 这 种 不 均衡 导致 他 们 的 知识 只 是 以 点 的 形式 存在 ,无 法 串 成 整体 ， 
此 那些 很 深入 的 研究 并 不 能 给 他 们 实际 工作 带 来 多 大 的 帮助 。 第 三 类 DBA 是 技巧 型 的 ， 他 们 并 
不 注重 理论 的 学 习 和 经 验 的 积累 , 在 处 理 问题 的 时 候 往 往 能 够 利用 Metalink 和 谷歌 、 百 度 之 类 的 
工具 去 搜索 解决 方案 ， 这 类 DBA 最 为 常见 。 他 们 处 理 问题 往往 靠 运气 ,而且 一 些 他 们 自 鸣 得 意 
的 成 功 案例 往往 也 是 经 不 起 推 殴 的 ， 下 回 碰 到 类 似 案例 时 ， 可 能 还 会 失败 。 第 四 类 DBA 是 虚心 
请 教 型 的 ， 他 们 无 论 碰 到 什么 问题 ， 甚 至 连 错误 信息 都 没有 看 明白 ， 就 开始 叫 “我 的 系统 出 问题 
了 ”， 然 后 到 处 去 问 如 何 解决 。 

实际 上 , 这 四 类 DBA 都 是 有 缺陷 的 。 第 一 类 DBA 可 能 经 过 多 年 的 工作 , 有 十 分 丰富 的 经 验 ， 
处 理 问 题 的 能 力 很 强 , 而 且 分 析 问 题 十 分 敏感 ,很 容易 抓 到 问题 的 关键 , 但 是 由 于 没有 深入 理解 
Oracle 的 理论 ， 磁 到 一 些 较 为 深入 的 问题 的 时 候 ， 就 不 容易 立刻 找到 关键 。 虽然 凭 借 着 自身 丰富 
的 经 验 和 问题 分 析 排 查 能 力 , 他 们 最 终 也 能 解决 大 部 分 的 问题 , 但 是 往往 问题 解决 后 还 是 没有 真 
正和 弄 明白 为 什么 会 解决 问题 ， 下 一 次 碰 到 类 似 的 问题 ， 可 能 还 是 要 花 很 大 的 代价 。 

第 二 类 DBA 在 某 些 方面 的 理论 知识 很 强 ， 总 是 喜欢 研究 一 些 十 分 高 深 的 原理 性 的 东西 ,但 
是 这 类 DBA 的 主要 精力 都 放 在 了 研究 一 些 Oracle 内 部 原理 上 了 ， 他 们 没有 很 多 的 时 间 去 实践 他 
们 学 到 的 理论 。 这 类 DBA 往往 知识 面 较为 狭窄 ， 仪 精通 于 自己 研究 比较 深入 的 领域 ， 在 实际 工 
作 中 也 很 难 发 挥 出 自身 的 理论 研究 特长 。 

第 三 类 DBA 实际 上 在 我 们 的 现实 生活 中 是 最 常见 的 ,“ 万 事 不 明 问 百度 , 百度 不 明 就 抓 月 ”， 
确实 谷歌 、 百 度 和 Metalink 能 够 帮助 我 们 解决 不 少 问题 ， 但 是 这 类 DBA 往往 在 问题 解决 后 没有 
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好 好 思考 一 下 ,为 什么 这 个 方法 能 够 解决 问题 ,更 没有 认真 总 结 和 归纳 一 下 ,下 一 次 碰 到 类 似 的 
问题 ， 还 是 无 法 依靠 自己 的 思考 去 解决 问题 。 于 是 再 Google 一 把 ， 也 许 这 一 次 运气 没有 那么 好 
T, Google 出 来 的 资料 不 是 上 回 的 那个 了 ， 于 是 结果 可 能 是 很 悲惨 的 。 

第 四 类 DBA 在 我 们 现实 生活 中 也 经 常 出 现 , 网 络 社会 通信 十 分 发 达 , 打 个 电话 或 者 在 qq 群 
里 、msn 里 问 问 ， 也 许 就 有 人 帮忙 解决 问题 。 和 久而久之 ,这些 人 放弃 了 自己 的 思考 ， 碰 到 一 点 点 
小 问题 都 要 找 人 问 。 缺 乏 独立 思考 问题 能 力 的 DBA， 只 能 称 为 一 个 数据 库 操 作 员 ， 实 际 上 离 真 
正 的 DBA 还 有 十 万 八 千里 呢 。 

看 到 这 里 ， 大 家 可 能 明白 了 , 老 白 实际 上 说 的 不 是 四 类 DBA， 而 是 DBA 的 四 种 性 格 ， 这 四 
种 性 格 可 能 会 集中 在 某 一 个 人 身上 。 以 老 白 学 习 DBA 的 经 验 来 看 , 理论 结合 实践 是 十 分 重要 的 。 
在 2000 年 前 ， 老 白 虽 然 做 了 很 多 项 目 ， 也 是 很 多 人 眼 里 的 Oracle 数据 库 高 手 ， 但 那 时 的 老 白 就 
是 第 一 类 DBA 的 典型 ， 没 有 经 过 多 少 理论 学 习 ， 几 乎 所 有 的 Oracle 数据 库 的 技能 都 是 从 实践 中 
获得 的 。 虽 然 在 实践 中 我 总 结 出 大 量 的 经 验 ， 甚 至 有 很 多 客户 建议 我 写 一 本 书 ， 把 我 对 Oracle 
的 理解 写 出 来 , 不 过 当 我 自信 满 满 地 开始 写 书 的 时 候 , 却 突然 发 现 , 我 的 一 些 知 识 需 要 进行 确认 ， 
否则 写 出 来 就 贻 笑 大 方 了 。 于 是 我 开始 大 量 地 学 习 Oracle 的 一 些 理论 知识 , 随 着 写 书 过 程 的 深入 ， 
我 越发 感到 自身 理论 水 平 的 不 足 。《Oracle 数据 库 深度 历险 》 这 本 书 我 写 了 3 年， 实际 上 2002 年 
就 彻底 放弃 了 出 版 这 本 书 的 念头 ,因为 我 发 现 自己 的 理论 知识 确实 还 需要 进一步 的 梳理 。 但 是 我 
并 没有 放弃 写作 ， 因 为 我 发 现 通 过 写作 , 我 更 为 系统 地 将 Oracle 的 理论 知识 梳理 了 一 遍 , 这 次 梳 
理 是 通过 我 以 前 的 知识 体系 、 工 作 经 验 ， 与 Oracle Concepts 的 理论 基础 进行 了 一 次 完整 的 整合 。 
通过 这 3 年 的 写作 , RATANA T AEK Oracle 的 理论 体系 , 好 像 一 个 练武 术 的 人 , 终于 打 
通 了 任 督 二 脉 ,感到 无 比 的 畅快 。 

听 老 白 说 了 这 么 一 大 通 ， 是 不 是 很 多 人 都 感觉 到 手脚 发 凉 ， 难 道成 为 一 个 合格 的 РВА 有 这 
么 难 吗 ? 如 果 我 没有 打通 任 督 二 脉 ,就 不 算 一 个 合格 的 DBA 吗 ? 实际 上 DBA 成 长 的 道路 是 很 多 
的 ,并 不 一 定 要 走 老 白 这 一 条 路 , 老 白 仅仅 是 根据 自身 的 经 历 , 通 过 这 本 书 来 帮助 大 家 梳理 Oracle 
的 一 些 基 础 知识 而 已 。 还 是 那 句 话 ， 如 果 Oracle 是 你 的 爱好 , 那么 你 无 论 花 多 大 代价 去 研究 它 都 
是 值得 的 ; 如 果 Oracle 只 是 你 职场 生涯 中 的 一 份 工作 而 已 , 那么 只 要 你 认真 对 待 它 就 可 以 了 , W 
必要 像 老 白 那 样 执著 。 

作为 一 个 DBA,， 理论 学 习 和 实践 如 何 相 结合 是 十 分 关键 的 。 在 初期 ,一般 来 说 DBA 都 是 通 
过 了 某 种 途径 接触 了 Oracle 数据 库 , 进行 了 一 系列 的 操作 。 在 工作 过 程 中 发 现 了 一 些 问题 , 才 开 
始 想到 需要 去 看 一 些 Oracle 的 书籍 。 在 这 个 阶段 ，Oracle 官方 文档 的 2days, 7 days 系列 人 门 书 
籍 就 十 分 有 效 。 通 过 这 些 书籍 你 可 以 了 解 Oracle 的 一 些 基本 的 原理 和 基本 的 操作 , 帮 你 在 工作 中 
解决 部 分 问题 。 这 样 你 在 工作 中 就 能 够 应 对 一 些 简单 的 问题 了 。 不 过 碰 到 稍微 复杂 一 些 的 情况 ， 
UR HEIRESS ЭЙ, 这 时 ，Oracle Concepts 这 本 书 就 十 分 关键 了 。 从 这 个 阶段 开始 看 这 本 书 是 十 
分 必要 的 , 它 有 助 于 你 在 积累 经 验 的 过 程 中 不 断 地 完善 理论 ,不 过 ,你 可 能 还 无 法 完全 理解 Oracle 
Concepts 中 的 基本 概念 ,通读 这 本 书 是 十 分 必要 的 , 但 是 不 必要 把 每 个 问题 都 搞 得 十 分 清楚 。 
为 要 达到 这 一 点 , 你 需要 花费 太 多 的 时 间 和 精力 , 同时 也 可 能 会 由 于 缺乏 足够 的 技术 指导 而 无 法 
真正 理解 问题 的 本 质 。 不 过 在 这 个 阶段 , 磁 到 某 些 问题 或 者 研究 各 种 案例 的 时 候 , 经 党 翻 翻 Oracle 


Concepts 这 本 书 是 十 分 有 益 的 ， 因 为 在 处 理 问题 的 时 候 ， 你 针对 这 个 问题 的 思考 会 比较 深入 , 这 
个 时 候 ， 认 真 分 析 一 下 相关 的 理论 是 十 分 有 效 的 。 对 于 处 理 过 的 每 一 件 事 情 ， 都 做 一 个 比较 详细 
的 记录 ， 是 十 分 好 的 习惯 。 记 录 下 某 个 案例 ， 可 以 供水 平 提高 后 再 进行 回顾 , 或 者 将 案例 提交 给 
某 个 专家 去 评审 , 或 者 在 网 上 和 大 家 一 起 讨论 , 对 于 学 习 Oracle 的 原理 都 是 十 分 好 的 方法 , 可 以 
帮助 你 在 分 析 案 例 时 提高 对 Oracle 数据 库 原理 的 认 知 。 

在 这 本 书 里 ， 老 白 会 把 《Oracle 数据 库 深度 历险 》 中 的 一 些 内 容 , 结合 老 白 的 实际 工作 经 验 
展现 给 大 家 。 我 会 剖析 原理 ,并 结合 案例 来 说 明 这 些 理论 知识 如 何在 实践 中 应 用 。 希望 老 白 的 这 
次 写作 经 历 ， 能 够 给 大 家 带 来 一 些 帮助 。 

(DBA 的 思想 天 空 》 二 次 印刷 了 ， 在 本 书 出 版 后 ， 大 量 读者 对 本 书 提出 了 勘误 。 老 白 在 此 对 
大 家 表示 感谢 ,只 有 认真 的 读者 ,才能 成 就 高 质量 的 图 书 。 图 灵 的 书 一 直 是 老 白 比较 言 欢 的 ， 
为 图 录 对 图 书 质量 的 把 控 一 直 很 严 。 虽然 作者 和 编辑 已 经 尽 可 能 认真 , 但 是 本 书 是 老 白 在 将 近 一 
年 的 时 间 里 完成 的 ， 其 中 难免 错漏 ， 甚 至 有 些 观点 也 不 尽 正 确 。 老 日 希望 在 和 大 家 分 享 自己 的 思 
想 心得 的 同时 ,大 家 也 能 帮助 老 白 发 现 书 中 的 问题 。 有 些 问题 其 至 可 以 通过 激烈 的 讨论 , 道理 是 
越 辩 越 明 的 。 其 实在 本 书 刚 开 始 写作 时 , 老 白 引用 了 一 个 共享 池 故 障 的 处 理 案例 , 不 过 由 于 后 来 
和 网 友 讨论 这 个 案例 的 时 候 , 发 现 有 一 些 支 撑 某 个 观点 的 依据 并 不 充分 , 因此 这 个 十 分 有 趣 的 案 
例 在 最 终 成 书 时 被 舍弃 了 。 因 为 这 一 点 不 明确 ， 可 能 导致 老 白 要 表达 的 某 个 观点 无 法 得 到 支撑 ， 
甚至 会 误导 读者 。 

老 白 会 继续 通过 写作 来 和 大 家 分 享 自己 对 Oracle 的 感悟, 也 十 分 希望 能 继续 和 大 家 互动 , 希 
望 大 家 继续 为 老 日 的 书 提 勘误 , 让 每 一 个 印 次 的 质量 都 能 有 所 提高 。 还 是 那 名 话 ， 只 有 认真 的 读 
者 才能 成 就 高 质量 的 图 书 ， 与 大 家 共勉 。 


阅读 本 书 的 建议 


本 书 还 是 一 本 介绍 方法 的 书 , 并 不 是 一 本 系统 介绍 Oracle 知识 的 百科 全 书 , 因此 读者 在 阅读 
本 书 时 应 该 注意 方式 方法 , 需要 注重 对 基础 概念 的 理解 和 对 工作 思路 的 理解 ,而 不 要 拘泥 于 某 个 
技术 细节 。 本 书 并 没有 涉及 任何 技术 细节 , 关于 技术 细节 , 读者 可 以 参考 Oracle 相关 的 官方 文档 ， 
比如 Complete Reference, Oracle Concepts, Oracle Performance Tuning Guide 等 。 实 际 上 ， 老 白 
认为 Oracle 的 官方 性 能 优化 手册 是 我 看 到 过 的 最 好 的 性 能 优化 方面 的 书籍 , 没有 之 一 。 如 果 你 认 
真 研读 过 这 本 技术 手册 , 就 会 发 现 你 以 前 看 到 过 的 关于 Oracle 性 能 调 优 的 书籍 的 核心 内 容 , 只 不 
过 是 对 这 本 书 的 另外 一 种 阐述 而 已 ， 可 能 会 增加 一 些 例子 , 可 能 在 某 些 细节 上 会 更 加 细致 , 仅 此 
而 已 。 

本 书 中 的 一 些 观点 仅仅 是 老 白 自己 这 些 年 对 Oracle 的 理解 , 并 不 是 金 科 玉 律 , 可 能 有 一 些 思 
路 和 方法 是 有 一 定局 限 性 的 , 甚至 有 些 或 许 是 错误 的 , 因此 读者 不 能 盲从 。 结合 自己 的 知识 体系 ， 
重新 认识 这 些 思 路 和 概念 , 使 之 成 为 自己 的 知识 体系 的 一 部 分 , 并 用 于 指导 你 建立 自己 的 问题 分 
析 、 预 案 处理 体 系 ， 才 是 最 为 根本 的 。 如 果 某 些 案 例 或 者 某 些 观点 你 不 太 认 同 ， 欢 迎 大 家 到 
www.oraclefans.cn 上 去 和 老 日 探讨 。 有 互动 的 阅读 ， 可 能 会 对 你 的 帮助 更 大 ， 也 有 助 于 老 白 纠正 
自己 的 一 些 错 误 。 

本 书 中 的 一 些 例子 都 是 比较 容易 去 实践 的 ， 老 白 其 实 仅仅 使 用 了 一 套 Oracle 10g 的 数据 库 、 
一 个 带 sql*plus 的 Oracle 客户 端 ， 再 加 上 profiler 工具 ， 就 完成 了 本 书 中 绝 大 多 数 实 验 。 希望 有 
兴趣 的 朋友 可 以 亲手 去 做 一 做 这 里 的 实验 。 如 采 大 家 觉得 里 面 的 脚本 自己 敲 出 来 很 麻烦 , 可 以 到 
www.oraclefans.cn 上 发 帖 癌 老 日 索取 。 不 过 老 白 觉得 , 如 果 你 能 看 懂 这 些 脚本 , 并 自己 再 写 出 来 ， 
那么 这 些 脚 本 就 真正 成 为 了 你 自己 的 工具 。 而 从 网 站 上 下 载 下 来 的 工具 ,可 能 很 快 就 会 被 你 丢弃 
在 一 边 ， 过 几 天 就 忘记 了 。 
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基础 原理 篇 


实际 上 对 于 Oracle 我 们 确实 还 需要 重新 去 认识 。 很 多 朋友 都 会 游泳 ， 那 么 我 来 问 一 个 简单 
的 问题 : 什么 叫做 真正 地 学 会 了 游泳 ? 每 个 学 游 闵 的 人 都 有 这 样 的 感受 ， 刚 刚 学 习 游 注 的 时 候 
最 大 的 问题 是 无 法 浮 在 水 面 上 ; 经 过 努力 ， 发 现 只 要 手脚 按照 一 定 方式 请 动 ， 身 体 放 平 就 能 浮 
在 水 面 上 了 ， 这 个 时 候 就 感觉 从 不 会 游泳 变 成 会 游泳 了 。 但 是 这 时 候 你 会 面临 另外 一 个 问题 ， 
就 是 不 会 换 气 ， 学 会 换 气 后 再 往 后 学 习 就 容易 了 很 多 ， 不 过 可 能 我 们 游 上 几 十 米 、 百 把 米 就 会 
觉得 很 累 。 后 来 我 们 发 现 ， 原 来 我 们 游泳 的 姿势 还 不 大 标准 ， 而 如 有 果 我 们 学 会 了 踩 水 ， 游 多 远 
都 不 是 个 问题 了 ， 这 个 时 候 我 们 就 如 鱼 得 水 了 。 学 习 Oracle 其 实 和 学 习 游 泳 十 分 类 似 ， 刚 刚 开 
始 的 时 候 ， 我 们 处 于 入 门 阶段 ， 要 克服 对 Oracle 的 妨 惧 心理 ， 只 要 我 们 想 学 好 Oracle， 我 们 就 
一 定 能 做 到 , 实际 上 Oracle 在 入 门 阶 段 是 十 分 容易 的 。 我 们 从 头 学 习 Oracle, 学 会 了 安装 数据 库 ， 
学 会 了 管理 表 空 间 ， 学 会 了 日 常 的 故障 处 理 。 就 像 我 们 学 游泳 的 时 候 刚 刚 学 会 换 气 一 样 ， 虽 然 
感觉 已 经 掌握 了 Oracle 数据库， 但 是 碰 到 稍微 复杂 一 些 的 问题 我 们 还 是 觉得 很 难 入 手 。 我 们 能 
看 清楚 一 些 东 西 ， 但 是 感觉 还 是 看 不 远 。 

上 面 这 种 情况 是 每 个 初学 者 都 会 碰 到 的 ， 学 Oracle 和 学 游泳 一 样 ， 刚 开始 的 时 候 我 们 只 是 
学 会 了 游泳 的 外 部 表现 ， 学 会 了 像 别 人 一 样 划 水 、 换 气 ， 但 是 并 没有 真正 掌握 游 冰 的 本 质 。 如 
果 要 消除 初学 期 的 迷茫 ， 我 们 一 定 要 真正 地 掌握 Oracle 数据 库 的 概念 ， 一 个 DBA 如 果 连 认真 
学 习 Oracle 的 基本 概念 都 不 能 做 到 ， 那 么 我 党 得 他 也 很 难 成 为 一 个 真正 的 高 手 。 

这 些 年 我 在 网 上 和 大 家 一 起 讨论 Oracle 的 问题 ， 也 经 常 有 朋友 问 我 ， 要 成 为 一 个 优秀 的 
DBA， 应 该 看 些 什么 书 。 我 给 大 家 推荐 的 第 一 本 书 就 是 Oracle Concepts， 这 也 是 我 唯一 能 够 推 
荐 给 所 有 人 的 书 。 这 本 书 确实 适合 任何 一 个 РВА 阅读 ， 无 论 你 是 初学 者 还 是 已 经 工作 了 很 多 年 
的 高 手 。 只 要 你 没有 认真 读 过 这 本 书 ， 你 就 有 必要 去 读 一 遍 。 


理解 Oracle 的 基本 原理 有 助 于 你 用 一 种 十 分 理性 的 思维 去 考虑 问题 ， 在 处 理 问 题 的 时 候 能 
够 更 快 地 抓 住 问 题 的 本 质 。 我 们 大 家 在 从 事 DBA 工作 的 时 候 ， 经 常会 碰 到 这 样 的 情形 ， 一 个 问 
题 困扰 了 我 们 很 长 时 间 ， 罕 然 猛 地 一 下 ， 你 就 抓 住 了 问题 的 关键 ， 然 后 它 就 迎刃而解 了 。 而 在 
这 之 前 , 我 们 可 能 会 做 过 很 多 尝试 , 这 些 尝 试 有 些 是 有 序 的 ， 有 些 是 无 序 的 ,甚至 有 些 只 是 睹 蒙 。 
在 这 种 情况 下 ， 有 时 候 经 验 是 帮助 不 了 你 的 ， 因 为 所 有 根据 经 验 的 分 析 都 已 经 做 完了 ， 并 且 被 
证 明 是 无 效 的 。 这 时 ， 我 们 就 只 能 根据 自己 对 问题 本 质 的 理解 去 分 析 ， 才 可 能 最 终 解 决 问题 。 

事实 上 ， 要 想像 Oracle 一 样 思 芳 ， 首 先 就 需要 了 解 Oracle 的 本 质 是 什么 ， 它 是 怎么 运作 的 ， 
在 运作 过 程 中 ， 哪 些 地 方 可 能 成 为 瓶 颈 。 这 个 时 候 可 能 就 有 朋友 感到 疑惑 了 : 我 们 如 何 了 解 
Oracle 内 部 运作 的 原理 呢 ? 这 看 似 一 个 不 可 能 完成 的 任务 。 确 实 ， 在 处 理 有 些 问 题 的 时 候 ， 我 
们 可 能 要 了 解 Oracle 很 深入 的 算法 ， 但 是 在 绝 大 多 数 情况 下 ， 我 们 分 析 癌 题 只 需要 了 解 一 些 我 
们 在 Oracle 官方 文档 中 提 及 的 原理 性 的 东西 ， 并 不 需要 深入 到 算法 和 源 代码 级 别 。 比 如 说 ， 如 
果 碰 到 一 个 共享 池 的 性 能 问题 , 你 会 马上 联系 到 共享 池 、 库 缓存 Clibrary cache)、 字 典 缓存 (row 
cache) , CURSOR , 以 及 相关 的 一 些 门 锁 、 参数 等 , 在 大 多 数 情况 下 这 些 就 可 以 支撑 你 做 分 析 了 。 
但 是 必须 把 这 些 知 识 点 编织 为 一 张 网 ， 而 不 是 一 个 一 个 的 知识 点 。 对 于 大 多 数 ОВА 来 说 ， 想 把 
这 些 知 识 点 编织 为 一 张 网 是 比较 难 的 。 这 需要 你 花费 大 量 的 时 间 来 学 习 ， 而 很 少 有 一 本 书 能 够 
从 这 个 角度 去 介绍 知识 。 因 此 这 种 学 习 会 比较 困难 。 在 本 章 ， 老 白 将 尝试 以 这 种 方式 来 介绍 相 
关 的 知识 点 ， 帮 助 大 家 从 知识 点 升级 为 一 个 立体 的 知识 体系 。 

另外 ， 把 知识 点 融会 贯通 不 是 看 书 就 能 达到 的 ， 要 想 达 到 这 个 目标 ， 必 须 进 行 足够 的 实践 
活动 。 你 只 有 在 把 学 到 的 知识 应 用 在 实践 中 ， 才 可 能 突破 知识 扳 岛 ， 达 到 新 的 境界 。 因 此 ， 如 
有 果 你 看 完 第 一 部 分 内 容 后 ， 有 些 知识 点 还 感觉 无 法 掌握 ， 这 也 并 不 要 紧 ， 结 合 自己 碰 到 的 案例 
思考 一 下 ， 也 许 会 更 有 收获 。 

第 一 篇 的 大 多 数 章 市 都 是 用 “理解 ”开头 ， 因 为 这 部 分 是 以 理解 Oracle 基本 原理 为 主要 宗 
旨 的 章节 。 通 过 本 篇 ， 老 白 希 望 大 家 能 够 对 以 前 有 一 定 认 识 的 Oracle 认识 得 更 为 深入 ， 那 么 你 
买 这 本 书 就 不 冤枉 了 。 


理解 Oracle 数据 库 和 实例 


数据 库 和 实例 是 Oracle 最 为 基础 的 两 个 概念 , 只 有 很 好 地 理解 了 什么 是 数据 库 , 什么 是 数据 
库 实例 , 才能 更 好 地 理解 Oracle 的 其 他 概念 。 本 章 将 会 通过 一 些 知 识 点 来 了 解 什么 是 数据 库 和 数 
据 库 实例 。 通 过 本 章 的 学 习 ， 我 们 也 会 更 加 适应 本 书 的 风格 。 


1.1 什么 是 Oracle 数据 库 


什么 是 Oracle 数据 库 呢 ? 这 是 一 个 我 经 常 问 DBA 的 问题 ,今天 我 要 来 回答 这 个 问题 。 说 到 
数据 库 ， 它 是 数据 的 集合 ,这 一 点 就 没 必 要 在 这 里 详细 讨论 了 。 大 多 数 介绍 数据 库 原理 和 数据 库 
基础 的 教材 要 比 我 解释 的 专业 得 多 。 这 里 只 讨论 “什么 是 Oracle 数据 库 ”。Oracle 数据 库 是 甲骨 
文公 司 开发 的 一 种 关系 型 数据 库 管理 系统 ， 也 就 是 RDBMS。 在 这 里 我 必须 插 几 句 ， 说 说 我 对 拉 
里 埃 里 森 的 崇拜 之 情 。 我 曾经 崇拜 过 乔布斯 ， 不 过 那 是 我 对 80 年 代 发 明 苹 果 电 脑 的 乔布斯 的 
EFE, YF iPhone 是 乔布斯 人 生 辉 煌 的 顶点 ， 但 是 我 只 崇拜 发 明了 那 台 绿 色 字 符 的 小 电脑 的 乔 
布 斯 ;我 也 曾 崇 拜 比尔 . 盖 茨 ， 不 过 那 是 我 对 DOS 3.0 的 崇拜 。 但 自从 听 说 了 拉 里 用 锤子 为 办 公 
室 开 辟 网 线 通道 的 故事 〈 不管 这 个 故事 是 不 是 真实 的 )， 我 就 开始 崇拜 他 了 。 用 圣 迹 来 命名 一 家 
公司 和 一 个 产品 ， 这 不 是 我 们 这 种 凡夫 俗 子 能 够 做 到 的 。Oracle 也 确实 像 圣 迹 一 样 ， 深 深 地 影响 
着 全 世界 。 

Oracle RDBMS 是 一 款 十 分 优秀 的 关系 型 数据 库 产 品 ，Oracle 从 头 到 尾 都 是 一 个 RDBMS, 
是 针对 OLTP 系统 进行 设计 的 ， 这 一 点 从 它 底层 的 块 结构 就 可 以 看 出 。Oracle 在 大 并 发 量 和 海量 
数据 关系 型 检索 方面 具有 十 分 优越 的 性 能 , 但 是 它 并 不 擅长 OLAP, 因为 它 不 支持 列 压缩 存储 ( 当 
然 ， 从 exadata 开始 ，Oracle 也 能 够 支持 混合 列 压 缩 ， 这 是 一 种 行 存 储 和 列 压 缩 的 混合 模式 ， 目 
前 只 在 exadata 数据 库 一 体 机 上 实现 )。 与 其 他 关系 型 数据 库 相 比 ，Oracle 在 某 些 方面 更 为 优秀 ， 
但 也 有 其 不 足 的 地 方 , 因此 它 绝对 不 是 万 能 的 。 优势 和 劣势 都 是 与 生 俱 来 的 , 这 是 由 Oracle 数据 
库 的 基本 架构 和 数据 存储 的 基础 结构 所 决定 的 , 优化 只 能 解决 局 部 性 的 问题 有 限度 地 提升 其 性 
ВЕ, 但 是 绝对 无 法 完全 掩盖 结构 性 问题 带 来 的 负面 影响 。Oracle 的 优势 在 于 大 并 发 量 下 的 高 否 吐 
能 力 ， 因 此 很 适合 大 型 企业 级 应 用 。 但 是 如 果 我 们 在 一 个 并 发 量 和 数据 量 都 不 是 很 大 的 系统 中 ， 
对 Oracle 和 MS SQL Server 进行 比较 ,就 不 难 发 现 Oracle 并 没有 多 大 的 优势 , 甚至 在 某 些 方面 还 
不 如 后 者 。 


4 第 1 章 理解 Oracle 数据 库 和 实例 


再 往 更 为 本 质 的 方面 去 探讨 ，Oracle 是 一 个 RDBMS 系统 ， 也 是 一 款 应 用 软件 。Oracle 数据 
库 除 了 将 数据 存储 于 文件 中 外 , 还 通过 一 个 被 称 为 实例 的 后 台 机 制 向 外 提供 服务 , 这 两 部 分 我 们 
将 在 随后 的 两 节 中 详细 介绍 ,这 里 不 做 过 多 的 描述 。 我们 在 这 里 仅仅 讨论 作为 应 用 程序 的 Oracle 
RDBMS 系统 ， 它 必须 依赖 于 某 个 操作 系统 或 硬件 体系 。 和 我 们 自己 编写 的 程序 一 样 ，Oracle 必 
须 适 应 于 某 个 操作 系统 ， 并 充分 利用 操作 系统 提供 的 资源 , 反 过 来 ,操作 系统 也 必须 能 够 将 资源 
提供 给 Oracle 数据 库 使 用 。 在 一 个 仅仅 运行 Oracle RDBMS 的 系统 上 , 操作 系统 应 该 被 调整 为 能 
够 将 绝 大 多 数 的 资源 都 提供 给 Oracle 数据 库 。 XEF, Oracle 的 进程 就 能 够 最 大 可 能 地 得 到 足够 的 
系统 资源 。 

讨论 这 个 似乎 又 有 点 跑题 了 ， 其 实 不 然 ， 只 有 充分 了 解 Oracle 的 本 质 ， 我 们 才 不 会 神化 
Oracle, Oracle 的 本 质 就 是 一 款 软件 、 一 个 程序 ， 那 么 它 就 具备 程序 的 一 切 特 征 ， 包 括 可 能 出 现 
HY bug. 

但 是 Oracle 不 是 一 个 简单 的 程序 ， 而 是 十 分 复杂 的 体系 。 首 先 ，Oracle 需要 将 数据 存储 在 数 
据 文 件 中 ,为 了 能 够 支持 大 量 的 并 发 用 户 访 问 数据 库 ， 并 且 提 高 数据 库 的 访问 性 能 ，Oracle 需要 
引入 共享 内 存 ， 从 而 实现 资源 的 共享 。 比 如 ， 针 对 SQL 引擎 ， 每 个 SQL 最 终 将 会 被 解析 为 一 系 
列 的 执行 步骤 ， 这 就 是 我 们 常 说 的 执行 计划 。 如 果 同 一 个 SQL 执行 多 次 ， 每 次 都 要 重新 生成 执 
行 计划 ,那么 效率 就 比较 低下 了 ，oOracle 引入 了 共享 池 来 实现 这 方面 的 共享 。 同 样 ， 如 果 一 个 数 
据 块 每 次 读 取 都 要 访问 文件 , 那么 效率 就 不 高 了 , 于 是 Oracle 引入 了 DB Cache 来 缓存 这 些 数据 。 
同一 个 数据 块 可 能 被 多 个 用 户 修改 , 如 果 每 次 修改 就 要 直接 存盘 ,那么 效率 也 会 降低 ,于 是 Oracle 
设计 了 DBWR 进程 ， 来 专门 负责 将 数据 块 写 人 文件 。 这 似乎 很 复杂 ， 不 过 这 一 切 对 于 架构 师 来 
说 很 好 理解 。 架 构 设 计 的 目的 就 是 有 效 地 将 功能 划分 成 不 同 的 组 成 部 分 , 然后 让 这 些 部 分 能 够 很 
好 地 协同 工作 ， 从 而 达到 最 好 的 效果 ， 因 此 架构 师 很 容易 做 出 类 似 的 设计 。 

实际 上 ,作为 一 个 应 用 程序 的 Oracle,， 它 的 实现 原理 是 十 分 朴实 的 ， 并 不 像 我 们 想象 的 那么 

申 秘 。 前 几 天 我 碰 到 一 个 案例 ， 有 个 客户 的 Oracle 9.2.0.6 数据 库 突 然 出 现 了 故障 ，sqlplus 通过 
sysdba 能 够 登录 ,并 且 能 够 访问 一 些 系统 视图 ， 比 如 v$session, 但 如 果 使 用 普通 用 户 登 录 就 会 被 
挂 起 。 通 过 HANGANALYZE 工具 分 析 , 没有 发 现任 何 异常 。 然 而 ,在 检查 Oracle 后 台 进 程 的 时 
候 , 我 们 发 现 所 有 的 Oracle 后 台 进 程 和 绝 大 多 数 前 台 进 程 都 消失 了 。 客户 很 是 不 解 ,为 什么 会 这 
PENG? 检查 日 志 ， 没 有 发 现任 何 异常 。 于 是 我 们 使 用 shutdown abort 关闭 了 实例 ， 并 且 进 行 了 重 
启 。 我 们 都 觉得 没有 日 志 ， 很 难 分 析 ， 也 就 没有 深入 研究 。 
第 二 天 ,客户 又 找到 了 我 , 说 数据 库 又 出 现 了 昨天 的 情况 , 这 回 所 有 的 Oracle 进程 ,包括 前 
台 进 程 、 后 台 进程 ， 统 统 没有 了 ， 而 且 没 有 任何 的 日 志 产 生 。 我 考虑 了 半天 ， 突 然 有 所 感悟 ， 
Oracle 的 实例 实际 上 也 是 一 款 应 用 软件 ， 由 多 个 进程 组 成 ,任何 一 个 进程 发 现 系 统 存在 异常 ， 都 
会 第 一 时 间 记 录 日 志 ， 如 果 问 题 十 分 严重 ， 就 会 关闭 实例 。 我 们 可 以 使 用 sysdba 账号 登录 系统 ， 
并 且 能 够 在 HANGANALYZE 工具 中 看 到 会 话 的 信息 , 说 明 Oracle 的 共享 内 存 还 存在 , 只 是 所 有 
的 进程 都 没有 了 。 这 种 情况 只 有 一 种 可 能 , 就 是 所 有 的 Oracle 后 台 进 程 都 是 在 同一 个 时 间 点 被 终 
止 的 ， 而 且 不 是 程序 自己 退出 的 (因为 程序 自己 退出 , 应 该 有 机 会 完成 自己 的 退出 业务 逻辑 ， 比 
如 写 日 志 记 录 故 障 )， 而 是 被 外 力 强 行 终止 的 。 
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从 上 面 的 分 析 , 很 自然 就 能 联想 到 Oracle 的 后 台 进程 很 可 能 是 被 人 为 杀 掉 了 。 于 是 我 做 了 一 
个 实验 ， 发 现 如 果 杀 掉 所 有 的 后 台 进 程 ，Oracle 的 共享 内 存 还 是 存在 的 ， 并 且 能 够 通过 sysdba 
账号 访问 ,普通 用 户 登 录 由 于 缺乏 后 台 进 程 的 支持 , 会 被 挂 起 。 这 个 现象 和 客户 目前 碰 到 的 问题 
十 分 相似 。 

发 现 这 个 问题 的 真相 只 有 一 个 渠道 , 就 是 从 应 用 程序 本 质 上 去 考虑 ,这样 才能 得 出 所 有 的 后 
台 进 程 都 是 在 同一 时 间 被 终止 的 结论 ， 并 找 出 其 原因 。 只 有 外 部 力量 的 介入 , 才 有 可 能 出 现 所 有 
后 台 进 程 全 部 终止 ， 而 共享 内 存 还 保持 正常 的 现象 , 这 绝对 不 是 某 个 bug 能 产生 的 结果 。 排 除了 
bug 的 影响 ， 我 们 才能 把 主要 精力 集中 在 正确 的 方向 上 。 

到 这 里 ， 对 于 这 个 案例 的 分 析 就 接近 尾声 了 ， 本 节 并 没有 很 深入 地 介绍 “什么 是 Oracle", 
而 是 更 加 直接 地 介绍 了 Oracle 的 本 质 。Oracle 在 本 质 上 就 是 一 组 应 用 软件 , 它 也 具备 所 有 应 用 软 
件 所 具备 的 特征 。 了 解 这 一 点 ， 是 我 们 今后 解决 任何 问题 的 基础 。 任 何 看 似 妖 异 的 现象 ， 都 离 不 
JF Oracle 作为 应 用 软件 的 本 质 ， 都 无 法 违背 应 用 软件 所 遵循 的 规律 。 

作为 应 用 程序 的 Oracle， 必 须 依赖 于 其 运行 的 系统 环境 ，Oracle 数据 库 的 处 理 能 力 和 性 能 
依赖 于 主机 硬件 、 存 储 、 网 络 和 操作 系统 等 因素 , 因此 作为 DBA 不 能 仅仅 就 Oracle M Oracle, 
还 必须 熟悉 Oracle 运行 所 依赖 的 环境 。 作 为 应 用 程序 的 Oracle, 会 和 操作 系统 中 的 其 他 进程 竞争 
有 限 的 系统 资源 ， 因 此 ,在 数据 库 服务 器 上 做 一 些 比较 大 的 操作 时 , 一定 要 讶 慎 ， 因 为 这 些 操作 
可 能 会 使 Oracle 数据 库 出 现 问题 。 

Oracle 不 仅 是 特殊 的 应 用 程序 ， 更 是 庞大 的 数据 库 管理 系统 ， 它 包含 了 一 个 RDBMS 管理 系 
统 和 其 他 一 系列 应 用 程序 ,Oracle 的 核心 一 一 RDBMS 管理 系统 包含 在 $6ORACLE_HOME/bin/oracle 
映像 、$ORACLE_HOME/ib/libclntsh.so 等 中 ， 而 sqlplus, exp 等 则 是 一 些 Oracle 数据 库 的 工具 。 
tnslsnr 是 Oracle 的 网 络 连接 部 件 , 用 于 连接 客户 端 到 RDBMS。 这 些 应 用 程序 都 被 安装 在 ORACLE 
HOME 目录 下 。 

通过 上 述 应 用 程序 ，RDBMS 管理 系统 及 其 工具 ， 用 户 就 可 以 创建 、 管 理 数据 库 。 另 外 , 用 
户 还 可 以 通过 sqlplus 工具 ， 使 用 create database 命令 去 创建 一 个 数据 库 ， 也 可 以 使 用 startup 和 
shutdown 命令 去 启动 和 关闭 数据 库 。 

数据 库 是 独立 的 ， 从 物理 结构 上 看 ， 它 是 由 一 系列 文件 组 成 的 ， 包 括 参数 文件 、 口 令 文件 、 
控制 文件 、 数 据 文件 、 日 志文 件 等 。 一 套 完 整 的 数据 库 ， 只 要 其 所 有 的 文件 都 是 完整 的 ,那么 即 
使 数据 库 的 RDBMS 管理 系统 遭 到 破坏 ， 只 要 重新 安装 和 数据 库 版 本 一 致 的 RDBMES 管理 系统 ， 
该 数据 库 就 可 以 重新 启用 。 其 实 所 谓 重 新 启用 ， 本 质 上 就 是 可 以 在 某 个 实例 中 打开 这 个 数据 库 ， 
供 客 户 使 用 。 

另外 需要 注意 的 是 ，Oracle 数据 库 是 一 个 RDBMS 管理 系统 ， 其 本 质 是 关系 型 数据 库 。 关 系 
型 数据 库 是 十 分 适合 OLTP 应 用 的 ， 因 为 它 存储 的 是 一 系列 的 关系 ,各 种 关系 以 表 的 形式 被 存储 
起 来 。 比 如 ， 春 节 前 铁路 网 上 售票 系统 朋 演 ,有 人 分 析 这 是 由 于 铁路 系统 固步自封 , 没有 使 用 国 
外 某 大 厂商 的 产品 , 而 选用 了 通用 RDBMS 数据 库 产品 所 导致 的 性 能 问题 ,如 果 选 用 了 某国 际 知 
名 三 商 的 网 状 数据 库 ， 就 不 会 有 问题 了 。 这 个 说 法 看 似 有 理 ， 实 际 上 ， 如 果 足 够 了 解 RDBMS, 
就 知道 其 不 值 一 驶 了 ， 因 为 铁路 售票 系统 是 十 分 典型 的 OLTP 应 用 。 
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另外 ,由 于 Oracle 是 行 存储 的 RDBMS 数据 库 ,这 一 特点 也 使 其 十 分 适合 OLTP 应 用 .从 Oracle 
数据 库 的 内 部 数据 结构 可 以 看 出 ，Oracle 在 行 存储 数据 方面 下 足 了 功夫 ， 甚 至 连 行 锁 都 是 设置 在 
行头 中 的 。 在 行 锁 的 性 能 方面 ，Oracle 的 表现 极为 优秀 ， 这 一 点 毋庸 置疑 。 不 过 这 种 设计 ， 可 能 
不 适合 一 些 经 常 以 列 为 访问 对 象 的 OLAP 系统 ， 列 压缩 技术 才 是 实现 这 类 应 用 的 最 佳 解决 方案 。 
因此 如 果 有 人 宣称 ，Oracle 数据 库 在 OLAP 分 析 方 面 的 性 能 高 于 SYBASE IQ， 那 一 定 不 可 信 。 


1.2 Oracle 数据 库 的 物理 结构 


Oracle 数据 库 的 物理 结构 从 本 质 上 来 说 就 是 一 系列 的 文件 。Oracle 数据 库 分 为 几 个 部 分 ， 第 
一 部 分 是 Oracle RDBMS 系统 的 安装 目录 ,也 就 是 我 们 党 说 的 ORACLE_HOME。.ORACLE_HOME 
包含 了 Oracle 运行 包 的 几乎 所 有 的 文件 ， 当 对 ORACLE HOME 执行 tar 命令 ， 并 将 其 复制 到 一 
台 具 有 相同 操作 系统 的 机 器 上 后 , 解 开 包 配 置 一 些 环境 变量 就 可 以 使 用 了 , 一 般 来 说 都 不 需要 做 
什么 特殊 的 处 理 。 不 过 由 于 我 们 安装 操作 系统 时 可 能 不 会 完全 一 致 ( 操作 系统 的 小 版 本 、 补 丁 包 、 
安装 的 可 选 包 等 )， 因 此 针对 通过 tar 命令 复制 过 来 的 介质 ， 应 在 使 用 前 做 一 次 重新 链接 。Oracle 
在 $ORACLE_HOME/bin 目录 下 ， 提 供 了 用 于 重新 链接 的 工具 ， 只 要 进入 该 目录 ， 执 行 : 

$relink all 
就 可 以 完成 Oracle 介质 的 重新 链接 。 当 然 为 了 便于 今后 管理 ,如果 要 复制 一 套 Oracle RDBMS 软 
件 介 质 ,不 能 仅仅 复制 ORACLE_HOME, ， 还 需要 创建 bdump udump HR, X Oracle 的 前 台 
和 后 台 进 程 输出 日 志 使 用 。 除 此 之 外 ， 还 有 一 个 十 分 重要 的 Oracle 组 件 需 要 进行 复制 ， 这 就 是 
Jnventory。 

Inventory 是 什么 呢 ? 很 多 做 了 多 年 维护 工作 的 DBA， 可 能 仍然 不 太 了 解 它 。 下 面 老 白 就 和 
大 家 一 起 讨论 Inventory。 


1.2.1 Inventory 


什么 是 Inventory 呢 ? Inventory Æ Oracle 安装 工具 OUI 用 来 管理 Oracle 安装 目录 的 .Inventory 
里 注册 了 某 个 ORACLE_HOME 下 安装 的 数据 库 的 组 件 及 其 版 本 。Oracle 数据 库 软 件 的 升级 、 增 
删 组 件 ， 都 需要 使 用 Inventory. 在 一 台 服 务 器 上 ，Oracle OUI 会 创建 一 个 全 局 的 Inventory, 全 局 
Inventory 的 目录 在 oralnst.loc 文件 中 指定 。 根 据 操作 系统 的 不 同 ，oraInstloc 所 在 的 目录 也 不 一 
样 。 在 AIX 或 者 LINUX 等 系统 中 ，oraInstloc 存放 在 /etc 目录 下 ， 在 有 些 操作 系统 中 ， 这 个 文件 
存放 在 /var/opt/oracle 目录 下 。oraInstloc 文件 中 包含 下 面 的 配置 项 目 : 


inventory_loc=<oralnventory 所 在 目录 > 
inst_group=<0UI 安装 0RACLE 的 操作 系统 组 > 


比如 说 ， 老 白 的 一 台 测 试 机 上 的 oralnst.loc 内 容 是 这 样 的 : 


inventory_loc=/opt/oracle/oralnventory 
inst groupzoi nstall 


这 里 面 有 两 个 信息 , 第 一 个 是 Inventory 所 在 的 目录 位 置 ,第 二 个 是 安装 Oracle 的 组 的 名 称 。 
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这 个 inst group 参数 十 分 重要 ， 它 会 在 link Oracle 映像 的 时 候 被 使 用 ， 如 果 这 个 参数 设置 错 了 ， 
那么 link 出 来 的 Oracle 映像 就 无 法 被 正常 使 用 了 。 
在 全 局 Inventory 中 定义 了 所 有 Oracle HOME 的 情况 ， 这 个 文件 就 是 ContentsKML 目录 下 的 


Inventory.xml: 


<?xml version="1.0" standalone="yes" ?> 


«!-- Copyright (c) 2001 Oracle Corporation. All rights Reserved --> 
«!-- Do not modify the contents of this file by hand. --» 
«Inventory» 


«VERSION INFO» 
«SAVED WITH»22.2.0.18.0«/SAVED WITH» 
«MINIMUM VER»2.1.0.6.0«/MINIMUM VER» 
«/VERSION INFO» 
«HOME LIST» 
«HOME NAME-"Oral0gHomel" LOC="/opt/oracle/product/10g" TYPE-"O" IDX-"1"/» 
«HOME NAME-"ora9i" LOC="/home/ora9i/product/9204" TYPE-"O" IDX="2"/> 
«/HOME LIST» 
«/Inventory» 


比如 上 面 的 例子 中 ， 老 白 的 系统 上 有 两 个 Oracle Home， 一 个 是 9i 的 一 个 是 10g 的 。 

在 ORACLE HOME 下 面 也 有 一 个 Inventory 目录 ， 这 个 目录 就 是 我 们 平时 说 的 Local 
Inventory 。 这 个 Inventory 是 本 地 的 ， 每 个 ORACLE HOME 所 独 有 的 。 它 记录 了 本 
ORACLE_HOME 中 OUI 安 装 的 组 件 的 信息 。 

TÉ Г Inventory 的 一 些 基础 知识 ， 下 面 我 们 就 要 聊 聊 了 解 这 些 知识 有 什么 好 处 了 。 假 设 这 
么 一 个 场景 , 我们 去 给 一 个 客户 的 数据 库 打 补丁 ， 到 了 客户 现场 ， 首 先 使 用 opatch lsInventory 来 
查看 一 下 当前 系统 的 情况 。 正 常情 况 显 示 的 数据 是 这 样 的 : 

Invoking OPatch 10.2.0.4.2 


Oracle Interim Patch Installer version 10.2.0.4.2 
Copyright (c) 2007, Oracle Corporation. All rights reserved. 


Oracle Home : /opt/oracle/product/10g 
Central Inventory : /opt/oracle/oraInventory 
from : /etc/oraInst.loc 

OPatch version : 10.2.0.4.2 

OUI version : 10.2.0.4.0 

OUI location : /opt/oracle/product/10g/oui 


Log file location : /opt/oracle/product/10g/cfgtoollogs/opatch/opatch2011-05-06 11 
-41-25AM.log 

LsInventory Output file location : /opt/oracle/product/10g/cfgtoollogs/opatch/lsinv/ 
lsInventory2011-05-06 11-41-25AM.txt 


Installed Top-level Products (4): 


Oracle Database 10g 10.2.0.r.0 
Oracle Database 10g Products 10.2.0.1.0 
Oracle Database 10g Release 2 Patch Set 3 10.2.0.4.0 
Oracle Database Vault 10.2.0.4.0 


There are 4 products installed in this Oracle Home. 


There are no Interim patches installed in this Oracle Home. 
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而 不 幸 的 是 ,我们 看 到 了 这 样 的 信息 : 


[oracle@ OPatch]$ ./opatch 151 пуепіогу 

Invoking OPatch 10.2.0.4.2 

Oracle Interim Patch Installer version 10.2.0.4.2 

Copyright (c) 2007, Oracle Corporation. All rights reserved 


Oracle Home : fopt/oracle/product/ 109 
Central Inventory : n/a 

from н 

OPatch version : 10.2.0.4.2 

OUI version : 10.2.0.4.0 

OUI location : fopt/oracle/product/10g/ oui 


Log file location : n/a 
OPatch cannot find a valid oralnst.loc file to locate Central Inventory. 
OPatch failed with error code 104 


和 客户 沟通 了 以 后 我 们 发 现 ， 这 套 系统 不 是 安装 的 ， 而 是 开发 商 直接 tar 过 来 的 。 碰 到 这 种 
情况 该 怎么 办 呢 ? 在 上 面 我 们 讲 过 ， 每 个 ORACLE HOME 下 面 都 有 本 地 Inventory， 在 本 地 的 
Inventory 中 也 已 经 注册 了 所 有 的 Oracle 组 件 的 信息 ， 那 么 我 们 就 可 以 通过 本 地 的 Inventory 来 创 
建 全 局 的 Inventory。 

重建 全 局 Inventory 的 方法 很 简单 , 第 一 步 我 们 首先 要 编辑 一 个 oraInstloc 文件 , 使 之 指向 我 
们 要 创建 全 局 Inventory 的 目录 。 


Inventory_loc=loptloracleloralnventory 
inst_group=oinstal 


然后 将 目录 转向 ORACLE HOME 下 的 oui/bin Н Ж: 
$ cd $ORACLE_HOME/ oui/ bin 
在 该 目录 下 执行 下 面 的 脚本 就 可 以 完成 全 局 Inventory 的 创建 : 


%./runlnstaller -silent -ignoreSysPrereqs -attachHome 
ORACLE НОМЕ =" <Oracle Ноте Location>" ORACLE HOME МАМЕ =" <Мате Of Oracle Home>" 


下 面 是 老 白 重 新 创建 自己 测试 机 上 的 Inventory 的 命令 : 


oracle@ bin]$ ./runlnstaller -silent -ignoreSysPrereqs -attachHome 
ORACLE HOMEz"/opt/oracle/product/10g" ORACLE НОМЕ NAME-"oral0g" 
Starting Oracle Universal Installer... 


No pre-requisite checks found in огарагат. ini, no system pre-requisite checks will be 
executed. 


>>> Ignoring required pre-requisite failures. Continuing... 


The Inventory pointer is located at /etc/oralnst.loc 
The Inventory is located at /opt/oracle/oralnventory 
"AttachHome' was successful 


这 个 命令 支持 Oracle 10.2, ХТ Oracle 9i 和 10.1 的 版 本 ， 如 果 丢 失 了 全 局 Inventory, HbA 
就 需要 从 一 个 类 似 的 平台 克隆 一 个 Inventory 过 来 。 克 隆 的 具体 方法 由 于 篇 幅 有 限 ， 在 这 里 就 不 
做 过 多 的 描述 了 ， 有 兴趣 的 朋友 可 以 参考 Metalink 上 的 下 面 几 个 文档 : 
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ote 559299,1 "Cloning An Existing Oracle9i Release 2 (9.2.0.x) RDBMS Installation m 
ior LOU "Cloning An Existing Oraclel0g Release 1 (10.1.0.x) RDBMS Installation 
i xpo "Cloning An Existing Oraclel0g Release 2 (10.2.0. x) RDBMS Installation 
x е "Cloning Ап Existing Oraclellg Release 1 (11. 1. 0. x) RDBMS Installation 
Using OUI" 
针对 11.2 以 后 的 数据 库 ， 这 个 命令 有 所 区 别 : 
% ./runinstaller -silent -ignoreSysPrereqs -attachHome 


ORACLE_HOME="<Oracle_Home_Location>" 

我 们 不 需要 指定 ORACLE_HOME 的 名 字 了 。 

刚才 的 例子 是 单 节 点 的 ， 在 RAC 环境 下 要 稍微 复杂 一 些 。 在 本 小 节 的 最 后 一 部 分 ， 我 们 来 
简单 探讨 一 下 重建 RAC 环境 下 的 全 局 Inventory 的 方法 。 
10g RAC 引入 了 CRS, 因此 我 们 在 重建 Inventory 的 时 候 , 至 少 需要 修复 两 个 ORACLE_HOME， 
一 个 是 RDBMS 的 , 一 个 是 CRS 的 。 命 令 如 下 : 


.I/runlnstaller -silent -ignoreSysPrereqs -attachHome ORACLE HOME="<10g Ora Crs Home 
Path>" ORACLE HOME МАМЕ =" <Name of oracleCRSHome»" LOCAL NODE-'nodel 

CLUSTER NODES-nodel,node2 CRS=true 

.Iruninstaller -silent -ignoreSysPrereqs -attachHome ORACLE HOME=" <109 Oracle Home 
Path>" ORACLE HOME МАМЕ =" <Name of oracleHome»" LOCAL NODE-' nodel 

CLUSTER NODES-nodel, node2 


1.22 口令 文件 


口令 文件 一 般 来 说 放 在 SORACLE_HOME/dbs AX F, 在 Windows 平 台 下 面 , 这 个 文件 是 在 
$ORACLE_HOME/database 目录 下 。 

Oracle 数据 库 的 口令 文件 存放 有 超级 用 户 的 口令 及 其 他 特权 用 户 的 用 户 名 7 口令。 在 创建 一 
个 数据 库 的 时 候 , 在 $ORACLE_HOME/dbs 目录 下 会 自动 创建 一 个 与 之 对 应 的 口令 文件 。 此 文件 
是 进行 初始 数据 库 管 理工 作 的 基础 。 在 此 之 后 ， 管 理 员 也 可 以 根据 需要 ， 使 用 工具 ORAPWD F 
工 创 建 口 令 文件 。 

默认 安装 下 ， 最 初 的 口令 文件 中 只 包含 sys 账号 的 信息 ， 我 们 来 看 看 老 白 的 测试 库 的 信息 : 

[oracle@ dbs]$ strings orapworc 

d E Remote Password file 

INTERNAL 


87C5F4BF47942D0E 
4CCF4A082AD3F 312 


这 时 候 如 果 想 把 system 账号 设置 为 sysdba 权限 ， 我 们 来 看 看 口令 文件 有 什么 变化 


[oracle@ dbs]$ sqlplus '/as sysdba 

SQL*Plus: Release 10.2.0.4.0 - Production on Fri May 6 12:18:25 2011 
Copyright (c) 1982, 2007, Oracle. All Rights Reserved 

Connected to: 


>: 
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Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production 
With the Partitioning, Oracle Label Security, OLAP, Data Mining 

and Real Application Testing options 

SQL» grant sysdba to system 

Grant succeeded. 


SQL» exit 

Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 
Production 
With the Partitioning, Oracle Label Security, OLAP, Data Mining 
and Real Application Testing options 

oracle@ dbs]$ strings orapworc 

\[Z 
ORACLE Remote Password file 

NTERNAL 
87C5F4BF47942D0E 
4CCF4A082AD3F 312 
SYSTE 
6971FF1AEA6387CE 


这 个 文件 中 包含 了 system 这 个 账号 。 同 样 我 们 也 可 以 给 其 他 账号 分 配 sysdba 权限 。 比 如 我 
们 授予 scott 账号 sysdba 权限 ,授权 后 ,在 口令 文件 中 就 保留 了 scott 账号 的 密码 信息 。 这 样 scott 
账号 就 可 以 在 数据 库 没 有 启动 时 进行 鉴 权 了 。 

我 们 可 以 使 用 orapwd 工具 重建 口令 文件 , 重建 的 方法 十 分 简单 ,我 们 就 不 在 本 节 中 多 说 了 。 


123 ”参数 文件 


参数 文件 一 般 来 说 放 在 $SORACLE_HOME/dbs 目录 下 , 在 Windows 平 台 下 面 , 这 个 文件 是 在 
%ORACLE_HOME“%/database 目录 下 。 早期 的 Oracle 数据 库 的 参数 文件 称 为 PFILE, 从 Oracle 9; 
开始 ， 引 人 了 服务 器 参 数 文 件 spfile。 和 pfile 不 同 ，spfile 采用 了 一 种 二 进 制 的 方式 ， 同 时 保留 了 
对 原 有 的 文本 参数 文件 的 支持 。 在 $ORACLE_HOME/dbs 下 存放 spfile 文件 ( 如 果 是 Windows `É 
£, 则 是 在 %ORACLE_HOME%b/database F )。Oracle 启动 的 时 候 会 按照 如 下 顺序 查找 参数 文件 : 
О $ORACLE_HOME/dbs/SPFILE.ORA 
口 SORACLE HOME/dbs/spfile.ora 
О $ORACLE_HOME/dbs/init.ora 

实际 上 ，spfile 也 不 完全 是 二 进 制 的 ， 只 是 在 原 有 的 pfile 基础 上 加 入 了 一 些 二 进 制 的 管理 和 
校 验 信息 ， 直 接 编辑 spfile， 可 以 取出 其 中 的 参数 配置 的 所 有 信息 。 

在 数据 库 启 动 的 时 候 , 数据 库 会 根据 搜索 路 径 自 动 查找 参数 文件 。 如 果 找 不 到 参数 文件 ， 数 
据 库 启动 会 失败 。 如 果 需 要 ， 可 以 使 用 下 面 的 方法 指定 一 个 启动 参数 文件 : 


sqlplus /nolog 
sql >connect sys/... as sysdba 
sql >startup pfilez$0RACLE HOME/dbs/init.ora; 


采用 服务 器 参数 文件 后 ， 参 数 文件 的 修改 就 相对 容易 了 一 些 。 可 以 通过 Oracle 提供 的 指令 
修改 : 
ALTER SYSTEM SET <PARAMETER>=<VALUE> SCOPE='SPFILE' 
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对 于 习惯 于 修改 文件 的 人 ， 可 以 使 用 下 面 方法 实现 类 似 Si 的 参数 修改 。 首 先 通过 下 列 语句 mE 
创建 一 个 文本 的 参数 文件 。 


sql>create pfile='... 


' from spfile; 


生成 参数 文件 后 可 以 手工 修改 。 但 是 每 次 修改 后 要 使 用 下 面 语句 生成 新 的 spfile。 


SQL>CREATE SPFILE-'... 


1.2.4 控制 文件 


控制 文件 是 Oracle 数据 库 中 十 分 重要 的 文件 ，Oracle 数据 库 启 动 时 ， 首 先 会 去 读 参数 文件 ， 
读 了 参数 文件 ， 实 例 所 需要 的 共享 内 存 区 和 后 台 进 程 就 可 以 启动 了 ， 这 就 是 数据 库 实例 启动 的 


nomount 阶段 。 完 成 这 个 步骤 以 后 ， 就 需要 通过 参数 文件 中 的 control files 


pei 


Mount 阶段 。 
控制 文件 中 包含 了 Oracle 数据 库 中 十 分 重要 的 信息 , 其 中 包括 整个 数据 库 的 物理 结构 、 所 有 
数据 文件 、 REDO LOG 文件 等 的 信息 。 当 然 控 制 文 件 中 还 包含 了 一 些 其 他 的 重要 信息 ， 比 如 归 
档 模式 下 的 日 志 归 档 情况 、rman 备份 时 的 catalog 信息 等 。 要 想 了 解 控制 文件 中 包含 哪些 内 容 ， 

可 以 通过 下 面 的 语句 进行 查询 : 


Select type,record size,records total,records used from 


' FROM PFILE='...'; 


v$controlfile record section; 


参 
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数 ， 找 到 数据 库 的 


判 文 件 ， 然 后 打开 控制 文件 ， 对 控制 文件 进行 校 验 。 这 就 是 Oracle 数据 库 实 例 局 动 过 程 中 的 


RECORD SIZE RECORDS TOTAL RECORDS USED 


DATABASE 

CKPT PROGRESS 

REDO THREAD 

REDO LOG 

DATAFILE 

FILENAME 
TABLESPACE 
TEMPORARY FILENAME 
RMAN CONFIGURATION 
LOG HISTORY 
OFFLINE RANGE 
ARCHIVED LOG 
BACKUP SET 

BACKUP PIECE 
BACKUP DATAFILE 
BACKUP REDOLOG 
DATAFILE COPY 
BACKUP CORRUPTION 
COPY CORRUPTION 
DELETED OBJECT 
PROXY COPY 

BACKUP SPFILE 
DATABASE INCARNATION 


n 


N ол 
Воо O O O Ооо O O с) Io Wor хо. №: OWE O FE 
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我 们 可 以 看 到 ， 控 制 文件 中 包含 了 数据 库 信 息 、CKPT 进程 信息 、REDO 信息 、 数 据 文件 
和 表 空 间 信息 等 重要 的 数据 库 信息 , 也 包含 了 日 志 切 换 的 历史 信息 和 RMAN 备份 的 CATALOG 
信息 


JUNO 


1.2.5 ”在线 日 志文 件 


在 线 日 志文 件 即 REDO LOG 文件 ,“ 在 线 ” 这 两 个 字 是 用 于 和 归档 日 志 区 分 的 。 在 线 日 志 
是 数据 库 中 十 分 重要 的 文件 ， 主 要 用 于 记录 数据 库 的 变更 信息 。Oracle 使 用 在 线 日 志文 件 记录 
数据 库 变更 信息 的 目的 是 ， 当 数据 库 实例 宕 掉 的 时 候 ， 可 以 通过 在 线 日 志文 件 中 记录 的 信息 进 
行 恢复 。 

在 线 日 志文 件 的 存在 , 解决 了 数据 库 实例 突然 宕 掉 或 者 服务 器 宕 机 后 的 系统 恢复 问题 。 有 了 
在 线 日 志文 件 , 就 不 用 害怕 Oracle 数据 库 突然 宕 掉 后 数据 库 实例 无 法 自动 修复 了 , 因为 它 的 固有 
机 制 可 以 确保 数据 库 完整 恢复 。 


1.2.6 ”数据 文件 


数据 文件 是 存储 Oracle 数据 库 中 的 数据 的 ， 也 是 Oracle 数据 库 中 最 为 核心 的 文件 。Oracle 
数据 库 中 的 表 、 索 引 等 都 是 记录 在 数据 文件 中 的 。 其 中 系统 表 空间 包含 的 数据 文件 里 保存 了 数据 
库 的 元 数据 ( metadata )， 这 部 分 数据 是 十 分 关键 的 ， 如 果 metadata 出 现 故 障 ， 那 么 我 们 在 访问 
数据 库 的 数据 时 就 会 发 生 问题 。 

数据 文件 中 还 有 一 类 特殊 的 文件 ， 即 临时 文件 ,一 般 来 说 ,临时 文件 属于 临时 表 空 间 。 临 时 
文件 是 Oracle 存放 临时 性 数据 的 ， 比 如 排序 数据 、 临 时 表 。 一 旦 数据 库 重启 ,临时 文件 中 的 内 容 
将 会 丢失 。 因 此 ， 我 们 不 能 把 永久 性 的 表 和 索引 存放 在 临时 文件 中 。 


1.2.7 ”归档 日 志文 件 


归档 日 志文 件 是 用 于 长 期 保存 的 ， 它 是 在 线 日 志 的 离线 拷贝 版 本 ， 当 在 线 日 志 切 换 的 时 候 ， 
ARCH 进程 就 会 将 这 个 刚刚 关闭 的 在 线 日 志文 件 的 内 容 复 制 到 磁盘 上 , 长 期 保存 。 归 档 日 志 的 主 
要 用 途 是 用 于 数据 库 的 恢复 操作 。 进 行 数据 库 完 全 恢复 或 者 不 完全 恢复 的 时 候 , 需要 将 备份 的 数 
据 文件 恢复 到 硬盘 上 ， 然 后 通过 归档 日 志 将 其 前 深 到 所 需要 的 时 间 点 。 

在 设置 了 逻辑 复制 的 环境 中 ,归档 日 志 也 有 可 能 用 来 进行 挖掘 ， 从 而 生成 LCR ( 逻辑 变化 
记录 ), 因此 在 配置 了 STREAMS, GOLDENGATE 等 逻辑 复制 的 环境 中 , 归档 日 志 需 要 在 磁盘 
上 存储 更 长 的 时 间 ， 以 便于 逻辑 复制 使 用 。 在 这 种 环境 中 ,保留 5 日 以 上 的 归档 日 志 是 十 分 必 
要 的 ， 如 果 你 的 存储 空间 足够 大 ,请 给 予 归 档 日 志 更 大 的 存储 空间 ， 并 且 这 些 归档 日 志 的 删除 
策略 也 要 做 适当 的 调整 ， 不 能 由 备份 软件 自动 删除 ， 而 是 要 通过 一 个 定时 任务 ， 删 除 几 天 前 的 
归档 日 志 。 
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如 果 有 人 问 “ 多 实例 数据 库 和 RAC 是 什么 关系 ”? 我 想 能 够 正确 回答 出 来 的 人 不 会 太 多 。 
要 回答 好 这 个 问题 , 首先 需要 知道 什么 是 Oracle 实例 , Oracle 实例 和 Oracle 数据 库 之 间 存 在 什么 
ХЖ. КАЖ DBA 都 学 习 过 实例 的 概念 ， 实 例 是 访问 Oracle 数据 库 的 通道 ， 包 含 共享 内 存 和 后 
台 进 程 。 一 个 Oracle 实例 一 次 只 能 打开 一 个 Oracle 数据 库 ， 而 一 个 Oracle 数据 库 可 以 同时 被 多 
个 实例 打开 。 被 多 实例 打开 的 Oracle 数据 库 ， 必 须 是 一 个 RAC 数据 库 。 

更 进一步 讲 , RAC 应 该 是 Oracle RDBMS 的 一 个 选 件 , 但 其 实 RAC 数据 库 的 说 法 并 不 严谨 ， 
不 过 我 们 大 可 不 必 过 分 纠结 于 此 问题 。 本 节 将 较为 全 面 地 介绍 多 实例 数据 库 。 


1.3.1 什么 是 数据 库 实例 


在 实际 的 开发 应 用 中 , 关于 Oracle 数据 库 , 经 常 听见 有 人 说 建立 一 个 数据 库 、 建 立 一 个 实例 
(Instance )、 启 动 一 个 实例 之 类 的 话 。 其 实 问 他 们 什么 是 数据 库 、 什 么 是 实例 ， 很 可 能 他 们 会 说 
“数据 库 就 是 实例 ， 实 例 就 是 数据 库 啊 ， 没 有 什么 区 别 ”。 我 只 能 说 虽然 他 们 使 用 了 很 长 时 间 的 
Oracle 数据 库 ， 也 算 积 累 了 一 定 的 经 验 ， 不 过 基础 的 概念 还 是 不 大 清楚 。 

我 们 都 知道 , 数据 库 就 是 存储 数据 的 一 种 媒介 , 数据 都 是 按照 某 种 格式 存储 在 某 些 特定 的 文 
件 中 的 。 我 们 比较 早 接触 过 的 数据 库 ， 比 如 说 DBASE, FOXBASE 之 类 的 ， 实 际 上 更 多 地 表现 
为 一 种 记录 管理 系统 ， 在 文件 中 按照 既定 的 格式 存储 了 一 些 数据 记录 。 早 期 开发 DBASE 应 用 的 
程序 员 可 能 还 记得 ,最 初 的 DBASE 数据 库 都 是 单机 环境 的 ， 因 此 在 开发 时 不 用 考虑 互 斥 和 锁 的 
问题 ， 只 需要 按照 业务 要 求 处 理 记 录 就 行 了 。 后 来 有 了 NOVELL 网 ，FOXBASE 得 到 了 广泛 的 
应 用 。 老 白 最 早 学 习 NOVELL 网 的 时 候 也 很 困惑 ， 对 于 FOXBASE 能 够 在 NOVELL 网 上 运行 感 
到 十 分 神秘 ， 后 来 明白 了 实际 上 NOVELL 网 为 FOXBASE 数据 库 提 供 了 一 个 共享 文件 系统 ， 
FOXBASE 正 是 通过 NOVELL 的 共享 文件 系统 在 多 个 网 络 终端 之 间 同 步 ， 这 样 一 来 在 NOVELL 
网 上 的 FOXBASE 应 用 就 十 分 容易 理解 了 。 在 FOXBASE 里 ， 我 们 通过 LOCK TABLE 命令 来 锁 
定 某 张 表 ， 然 后 再 对 其 进行 访问 和 修改 ， 这 样 就 可 以 避免 多 用 户 环境 下 的 冲突 问题 了 。 

刚才 似乎 扯 得 有 点 远 了 , 反 过 头 来 ,我 们 再 来 认识 Oracle 数据 库 。Oracle 数据 库 是 一 种 支持 
高 并 发 的 RDBMS 系统 , 因此 Oracle 也 需要 解决 在 大 量 并 发 用 户 下 的 一 致 性 访问 问题 。Oracle 数 
据 库 对 外 提供 的 访问 方式 并 不 是 应 用 程序 直接 打开 数据 文件 来 操作 数据 库 ， 而 是 通过 一 种 
TWO-TASK 的 模式 提供 服务 。 在 这 种 架构 下 ， 应 用 无 法 直接 访问 数据 库 ， 而 必须 通过 一 种 被 称 
为 实例 (Instance ) 的 逻辑 结构 去 访问 数据 库 。 

于 是 我 们 需要 了 解 一 个 十 分 重要 的 新 概念 一 一 实例 。 那么 什么 是 实例 呢 ? 官方 的 说 法 , 实例 
指 的 就 是 操作 系统 中 一 系列 的 进程 以 及 为 这 些 进程 所 分 配 的 内 存 块 。 如 果 用 更 容易 理解 的 方式 来 
解释 ， 那 就 是 说 Oracle 数据 库 的 实例 是 我 们 访问 Oracle 数据 库 的 通道 。 

下 面 我 们 先 来 了 解 一 些 数 据 库 实例 的 基础 概念 。 在 一 个 数据 库 实例 中 , 包含 了 Oracle 的 共享 
内 存 和 一 系列 的 后 台 进程 , 一 个 实例 在 同时 只 能 打开 一 个 数据 库 , 而 一 个 数据 库 可 以 同时 被 多 个 
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实例 打开 ， 当 然 了 ， 这 种 情况 就 是 我 们 常 说 的 RAC. Oracle 数据 库 的 实例 必须 依赖 于 某 个 特定 
的 ORACLE_HOME， 启 动 实例 需要 的 所 有 的 程序 和 相关 的 文件 (除了 数据 库 外 ) 都 包含 在 
$ORACLE_HOME "F, 除 此 之 外 , 每 个 实例 都 有 自己 独立 的 SID. 在 同一 个 ORACLE HOME Т, 
允许 启动 多 个 实例 ， 但 是 这 些 实例 必须 拥有 不 同 的 SD。 男 外 ， 一 个 非 RAC 的 数据 库 是 不 允许 
被 多 个 实例 打开 的 ， 因 为 实例 mount 独立 数据 库 的 时 候 ， 是 以 排他 的 方式 进行 的 。 一 个 RAC 的 
数据 库 ， 只 允许 同一 个 RAC 集群 中 的 多 个 实例 打开 ， 非 相同 集群 的 节点 是 无 法 打开 同一 个 数据 
库 的 。 

通过 上 面 的 介绍 ， 我 们 了 解 了 实例 、 数 据 库 、ORACLE_HOME SID 这 些 概念 之 间 的 关系 ， 
下 面 我 们 进一步 来 了 解 实例 。 在 Oracle 中 ， 我 们 可 以 启动 一 个 Oracle 的 实例 ， 这 个 时 候 虽 然 有 
了 进程 还 有 SGA 等 一 系列 的 内 存 块 ， 但 是 并 没有 把 数据 库 文 件 读 取 进 来 。 实 例 启 动 后 ， 为 访问 
Oracle 数据 库 的 应 用 提供 了 一 个 基础 的 环境 。 这 个 基础 环境 包含 了 一 组 共享 内 存 , 后 者 又 包含 了 
Oracle 数据 库 的 一 系列 内 部 数据 结构 ， 也 包括 了 Oracle 数据 库 的 SQL 和 数据 字典 缓冲 ( 共享 池 
中 的 库 缓 存 和 字典 缓存 ), 还 有 数据 块 缓冲 (DB Cache )。 在 一 个 启动 了 Oracle 实例 的 UNIX £ 
统 上 ， 使 用 ipcs 命令 可 以 看 到 共享 内 存 的 情况 : 


[огас1е@ ~]$ ipcs 
Ecc Shared Memory Segments -------- 


key shmid owner perms bytes nattch status 
0x9a8837b4 163840 oracle 640 1050673152 20 

====== Semaphore Arrays 一 一 一 一 一 一 一 一 

key semid owner perms nsems 

0x03c13d24 753664 oracle 640 154 


我 们 可 以 看 到 ，Oracle 用 户 分 配 了 一 组 共享 内 存 和 信号 灯 ， 这 和 我 们 在 UNIX 下 编写 具有 共 
享 内 存 的 应 用 程序 并 无 不 同 。 实 例 启动 时 首先 会 装载 参数 文件 , 根据 参数 文件 中 定义 的 内 存 相关 
参数 创建 共享 内 存 和 信号 灯 ， 然 后 将 参数 文件 装载 到 共享 内 存 中 被 称 为 ksppi 的 内 存 区 域 ， 同 时 
将 当前 实例 的 参数 装载 到 一 个 独立 的 区 域 一 一 ksppsv。 根 据 参数 文件 ， 启 动 进程 完成 SGA 中 内 
存 结构 的 初始 化 工作 ， 然 后 启动 相关 的 后 台 进 程 。 这 个 过 程 完成 后 ， 数 据 库 实 例 启动 的 第 一 步 
nomount 就 完成 了 。 

实例 启动 到 nomount 后 ， 所 有 的 共享 内 存 和 后 台 进 程 就 都 已 经 装载 完毕 。 于 是 ,系统 根据 参 
数 文件 中 控制 文件 的 位 置 , 打开 控制 文件 , 并 对 控制 文件 进行 校 验 , 如 果 这 个 步骤 没有 发 现 问题 ， 
就 完成 了 mount 步 又。 

数据 库 实例 mount 完成 后 ， 通 过 对 控制 文件 、UNDO 和 REDO 等 进行 比 对 分 析 后 ， 发 现 数 
据 库 状态 是 一 致 的 , 数据 库 实例 就 可 以 打开 数据 库 了 。 数据 库 打开 后 ,数据 库 实例 就 可 以 提供 对 
外 服务 了 。 

数据 库 实例 启动 过 程 在 很 多 书 中 都 有 十 分 详细 的 介绍 , 因此 本 节 就 不 再 著述 。 数据库 实例 启 
动 后 ， 应 用 程序 就 可 以 通过 数据 库 实例 来 访问 数据 库 了 。 

应 用 要 访问 Oracle 数据 库 , 可 以 通过 三 种 方式 : 第 一 种 方式 是 应 用 进程 直接 访问 数据 库 实例 
的 共享 内 存 , 第 二 种 方式 是 通过 Бед 协议 在 本 机 上 访问 , 第 三 种 方式 是 通过 网 络 协 议 访 问 。 第 一 
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种 方式 使 用 的 场合 很 少 ， 我 们 不 做 讨论 。 下 面 着 重 讨论 通过 第 二 种 和 第 三 种 方式 访问 数据 库 。 

首先 , 后 两 种 访问 数据 库 的 方式 都 是 基于 two-task 结构 的 ， 都 需要 在 数据 库 服务 器 上 建立 一 
个 服务 进程 ( server 进程 ， 或 者 前 人 台 进 程 ) 来 为 客户 端 应 用 服务 在 这 里 我 们 只 讨论 独立 服务 器 
模式 ， 共 享 服务 器 模式 十 分 类 似 , 我 们 将 在 后 面 进行 专题 描述 )。two-task 架构 下 访问 数据 库 , 首 
先 需 要 在 服务 器 端 创 建 一 个 进程 ,这 个 进程 启动 时 先 要 映射 共享 内 存 , 然后 才能 够 通过 共享 内 存 
中 的 内 部 数据 结构 完成 会 话 的 初始 化 工作 。 

在 本 机 上 不 经 过 SQL*Net 连接 数据 库 ， 前 台 进 程 和 用 户 进 程 之 间 通 过 IPC 机 制 进行 通信 ， 
通信 协议 就 是 著名 的 Bequeath ИМХ, 简称 BEQ 协议 。 而 如 果 通 过 SQL*Net 连接 数据 库 , 那么 就 
需要 使 用 网 络 协 议 。 现 在 TCP/IP 协议 已 经 成 为 使 用 最 为 广泛 的 协议 ， 因 此 我 们 主要 面 对 的 是 
TCP/IP 协 议 ， 而 10 多 年 前 ， 著 名 的 SPX 协议 、DECnet 协议 Token Ring 协议 等 都 曾经 是 DBA 
进程 配置 的 协议 。 使 用 SQL*Net 协议 的 前 台 进 程 和 用 户 进程 之 间 的 通信 采用 Socket 通信 。 实 际 
E, 在 服务 器 上 , 我 们 也 可 以 使 用 SQL*Net 连接 数据 库 ， 只 不 过 我 们 很 少 会 去 这 样 做 , 因为 BEQ 
协议 在 效率 上 高 于 Socket 通信 。 

除了 使 用 的 协议 不 同 ,在 本 机 上 通过 BEQ 协议 连接 数据 库 实例 和 通过 SQL*Net 连接 数据 库 
实例 还 有 什么 不 同 吗 ? 很 多 DBA 可 能 会 感觉 有 所 不 同 , 因为 在 本 机 上 直接 连接 数据 库 协议 , 前 台 
进程 是 shell 进 程 产生 的 子 进程 ;而 通过 SQL*Net 连 接 数 据 库 实例 ,server 进 程 是 LISTENER( tnslsnr ) 
产生 的 子 进程 ， 如 果 监 听 器 进程 的 属性 不 同 , 那么 产生 的 子 进程 会 和 shell 直接 产生 的 子 进程 有 所 
不 同 。 这 一 点 不 同 在 早期 的 Oracle 版 本 中 确实 存在 , 而 自从 $ORACLE_HOME/bin/oracle 这 个 映像 
文件 被 设 定 为 s 属性 后 ， 这 个 问题 就 不 存在 了 。Oracle 映像 通过 s 属性 可 以 将 子 进程 的 属性 转 为 
Oracle 用 户 。 

不 过 使 用 BEQ 协议 和 网 络 协 议 在 服务 进程 方面 还 是 有 所 不 同 的 ，BEQ 协议 通过 IPC 通信 ， 
因此 不 需要 使 用 Socket, 而 通过 网 络 协议 ( SQL*Net ) ERE, 客户 进程 最 初 连接 的 是 tnslsnr 进程 ， 
tnslsnr 进程 接受 了 连接 请 求 后 ， 为 其 创建 一 个 子 进 程 ， 然 后 通知 客户 端 进程 重新 连接 到 子 进 程 上 
继续 工作 。 在 这 个 时 候 ， 就 存在 一 个 Socket 重 定向 的 问题 。 监 听 器 产生 子 进程 时 会 为 新 的 连接 
分 配 一 个 未 被 使 用 的 端口 号 , 这 个 子 进程 启动 后 就 在 该 端口 上 侦 听 , 同时 监听 器 会 通知 客户 端 进 
程 ， 要 求 其 重 定向 到 新 的 端口 号 。 此 时 客户 端 进 程 会 关闭 老 的 Socket， 并 打开 一 个 新 的 Socket, 
完成 登录 操作 。 

可 能 有 些 DBA 对 上 面 的 讨论 感到 有 些 迷 落 了 ， 怎 么 讨论 实例 的 问题 ， 一 下 子 又 转 到 了 监听 
器 的 工作 机 制 上 上 了， 这些 知识 对 于 DBA 又 有 什么 作用 呢 ? 我 们 刚才 一 直 在 强调 实例 是 客户 端 访 
问 数据 库 的 通道 ， 因 此 讨论 客户 端 如 何 通过 监听 器 连接 数据 库 就 十 分 有 意义 了 。 

首先 第 一 点 , 现在 很 多 客户 对 系统 安全 性 要 求 很 高 ,因此 服务 器 上 大 量 的 网 络 端口 是 被 封 掉 
的 ， 只 有 必须 使 用 的 才 会 被 开放 。 那么 对 于 Oracle 数据 库 来 说 , 我 们 只 需要 开放 监听 器 所 需要 的 
端口 就 可 以 了 吗 ? 事实 上 不 是 这 样 的 ， 除 了 开放 类 似 1521 的 监听 端口 外 ， 我 们 还 需要 开放 一 些 
高 端口 ， 这 些 端口 将 被 用 于 Socket 重 定向 。 

可 能 很 多 用 户 在 客户 端 连 接 数据 库 的 过 程 中 经 常会 碰 到 TNS-12535 之 类 的 错误 ， 开 始 的 时 
是 从 网 络 超时 的 角度 去 分 析 , 不 过 这 样 分 析 往 往 很 难 找到 真正 的 故障 原因 。 这 类 问题 在 一 个 
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存在 防火 墙 的 环境 中 ， 往 往 是 由 于 在 防火 墙 环境 下 的 Socket 重 定 向 引起 的 ， 特 别 是 在 有 NAT 27) 
能 的 防火 墙 上 ， 这 类 问题 很 容易 出 现 。 客 户 端 连接 的 是 一 个 NAT 翻译 后 的 卫 地 址 ， 而 重 定向 的 
时 候 ， 监 听 器 要 求 客 户 端 连接 到 真实 的 IP 地 址 上， 这样 就 会 出 现 连 接 超 时 导致 的 失败 。 这 种 情 
况 一 般 的 解决 方案 是 使 用 connect manager (CMAN )， 老 白 也 曾经 碰 到 过 几 个 这 样 的 客户 ， 最 后 
都 是 通过 CMAN 来 彻底 解决 问题 的 。 


1.3.2 ”多 实例 数据 库 


多 实例 数据 库 的 概念 同样 经 常 让 DBA 感到 迷惑 ,多 实例 数据 库 可 以 说 是 RAC 的 另外 一 种 称 
IË, Oracle RAC 的 特点 就 是 多 个 数据 库 实例 可 以 同时 打开 相同 的 数据 库 ， 进 行 并 发 的 操作 。 多 
实例 数据 库 是 Oracle 高 可 用 架构 和 高 可 扩展 性 架构 的 核心 技术 ,多 个 实例 同时 打开 数据 库 进行 读 
15, 可 以 避免 某 个 实例 故障 导致 的 系统 不 可 用 ,同时 多 实例 实现 负载 分 担 , 也 可 以 减轻 某 个 实例 
的 工作 负载 ， 从 而 提高 整体 否 吐 能 力 。 

Oracle RAC 是 多 实例 数据 库 的 正式 名 称 ,， RAC 具有 很 多 激动 人 心 的 特性 , 但 是 实施 RAC 也 
有 一 些 潜在 的 风险 。 在 实施 之 前 ， 我 们 必须 认真 地 了 解 RAC 的 一 些 基 本 概念 。 

RAC 多 实例 数据 库 架 构 有 几 个 基础 。 第 一 个 基础 是 共享 存储 ， 多 台 服 务 器 (一般 来 说 我 们 
称 之 为 节点 ) 可 以 同时 并 发 读 写 相同 的 文件 。 如 果 没 有 这 个 基础 ，RAC 就 无 从 谈 起 。 我 们 可 以 
使 用 很 多 技术 来 实现 共享 存储 ， 最 为 普遍 使 用 的 就 是 存储 局 域 网 络 SAN， 通 过 光纤 交换 机 连接 
的 共享 存储 ， 一 组 lun 可 以 同时 被 多 个 服务 器 节点 访问 。 除 了 SAN 外 ， 以 NETAPP 为 代表 的 基 
于 TCP/IP 的 存储 解决 方案 也 是 КАС 的 可 选 方案 , 通过 ISCSI 或 者 NFS 共享 文件 系统 , 同样 可 以 
满足 RAC 对 于 共享 存储 的 需要 。 在 底层 的 可 共享 硬件 的 基础 上 ， 对 于 裸 设备 或 者 除了 NFS 外 的 
非 共 享 文件 系统 ，RAC 还 需要 依赖 于 操作 系统 提供 的 并 发 存储 支持 ， 人 允许 软件 并 发 访问 底层 存 
й. ША ІВМ 的 HACMP 提供 的 并 发 VG 的 支持 ， 允 许 同一 个 VG 在 多 个 节点 上 同时 被 激活 。 
另外 在 此 基础 上 的 集群 文件 系统 (CFS ) 也 是 实施 部 署 RAC 的 不 错 的 平台 。 从 10g 开始 ，Oracle 
也 提供 了 一 个 自己 的 共享 存储 解决 方案 ASM， 在 底层 提供 共享 的 存储 硬件 的 基础 上 ，Oracle 可 
以 不 使 用 第 三 方 的 共享 存储 解决 方案 ， 仅 仅 使 用 自己 的 ASM 技术 ,实现 类 似 HACMP 并 发 VG 
或 者 赛 门 铁 克 CFS 的 功能 。 

除了 共享 存储 外 ，RAC 还 需要 依赖 于 CLUSTERWARE。 在 10g ZA, RAC 必须 使 用 各 个 厂 
商 提 供 的 CLUSTERWARE， 比 如 JIJBM 的 HACMP、HP 的 MCSG 和 TRU64 CLUSTER。 另 外 也 
可 以 使 用 第 三 方 厂商 提供 的 CLUSTERWARE ， 比 如 赛 门 铁 克 的 STORAGE FOUNDATION 中 的 
CLUSTER 组 件 。 从 Oracle 10g 开始 ，RAC 完全 可 以 脱离 第 三 方 的 CLUSTERWARE， 而 使 用 
ORACLE 自己 的 CRS。CRS 是 Cluster Ready Services 的 简称 ，CRS 提供 了 RAC 数据 库 系统 所 必 
需 的 运行 环境 。 而 且 从 10g JF, RAC 数据 库 (RAC RDBMS ) 必须 依赖 于 CRS, 无 论 你 是 否 安 
装 了 第 三 方 的 CLUSTERWARE, RAC RDBMS 的 底层 堆栈 只 能 在 CRS 的 基础 上 运行 。 

这 里 有 一 个 读者 很 容易 混淆 的 概念 ， 就 是 CRS ЯП КАС 之 间 的 区 别 。 很 多 DBA 认为 CRS 就 
是 RAC，RAC 就 是 CRS， 实 际 上 这 是 一 个 十 分 错误 的 认 知 。RAC 更 严格 地 说 是 RAC RDBMS, 
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RAC 只 是 Oracle RDBMS 的 一 个 选 件 ， 安 装 并 启用 了 RAC 功能 的 数据 库 我 们 称 之 为 RAC 
RDBMS, ， 这 是 一 个 多 实例 的 关系 型 数据 库 系 统 。 而 CRS 只 是 一 个 CLUSTER 的 组 件 ， 它 提供 了 
RAC RDBMS 运行 所 必需 的 底层 集群 环境 。CRS 本 身 也 不 提供 共享 存储 系统 ， 它 只 提供 了 
CLUSTER 的 节点 管理 、 健 康 性 检查 以 及 一 系列 CLUSTER 应 用 (比如 VIP、ONS 等 应 用 ), 真正 
在 ВАС 中 提供 共享 存储 的 是 ASM, НАСМР 或 者 CFS 等 技术 。 

一 个 多 实例 的 数据 库 系 统 ， 必 须 运 行 在 CLUSTERWARE 环境 中 ， 同 时 CLUSTERWARE 也 
对 RDBMS 的 运行 情况 进行 一 定 限度 的 监控 。 以 10g CRS 为 例 ，RAC RDBMS 启动 时 必须 依赖 
CLUSTERWARE 环境 , 但 是 反 过 来 ，CRS 可 以 不 知道 RAC RDBMS 的 存在 , 也 就 是 说 一 个 RAC 
数据 库 实例 可 以 不 经 过 在 CRS 的 OCR 中 注册 而 独立 启动 ， 而 不 会 影响 RDBMS 的 正常 功能 。 但 
是 如 果 CRS 不 知道 这 个 数据 库 的 存在 ， 那 么 这 个 数据 库 及 其 实例 就 都 不 在 其 监控 之 中 ,一旦 某 
个 数据 库 实例 出 现 故 障 ，CRS 也 不 会 做 出 相应 的 反应 ， 比 如 重启 节点 等 。 

多 实例 数据 库 系统 的 一 个 很 重要 的 特性 是 多 个 实例 可 以 并 发 对 同一 个 数据 进行 读 写 , 这 一 点 
也 是 RAC 十 分 核心 的 功能 。 不 过 在 多 实例 数据 库 环境 中 ， 每 个 实例 都 拥有 自己 独立 的 SGA， 为 
了 确保 数据 库 的 一 致 性 ，Oracle RAC 系统 需要 使 用 一 个 被 称 为 缓冲 区 融合 (CACHE FUSION ) 
的 技术 来 实现 多 个 节点 上 的 缓冲 区 的 一 致 性 访问 。 因 此 , 在 多 实例 数据 库 中 修改 数据 ,需要 一 些 
额外 的 成 本 。 除 了 Oracle 锁 ( ENQUEUE ) 被 扩展 为 全 局 资源 外 ,如果 一 个 BUFFER 在 多 个 实例 
中 被 访问 ， 那 么 这 个 BUFFER 也 就 会 成 为 全 局 BUFFER。 对 于 全 局 BUFFER 的 访问 ， 其 开销 是 
要 比 普通 的 BUFFER 大 一 些 的 ， 因 为 每 次 访问 都 需要 向 某 个 BUFFER 的 MASTER 节点 咨询 该 
BUFFER 的 情况 , 并 由 MASTER 节点 来 授权 对 该 BUFFER 的 各 种 访问 。 在 早期 的 Oracle RDBMS 
版 本 中 ,， 某 个 BUFFER fJ MASTER 节点 从 该 BUFFER 被 装载 到 被 换 出 ， 是 不 会 发 生变 化 的 。 这 
样 一 种 机 制 , 导致 了 某 个 BUFFER 的 MASTER 节点 不 一 定 是 访问 这 个 BUFFER 最 多 的 节点 , 从 
而 也 导致 了 一 些 不 必要 的 网 络 包 用 来 处 理 MASTER 节点 和 访问 节点 之 间 的 交互 请 求 信息 。 从 
10.0.1.2 开始 ，Oracle 提供 了 一 种 新 的 机 制 ， 即 动态 REMASTER 机 制 DRM， 这 个 机 制 的 出 发 点 
是 某 个 资源 的 MASTER 节点 不 是 一 成 不 变 的 ， 而 是 根据 该 资源 被 某 个 节点 的 访问 频率 的 改变 ， 
自动 进行 动态 的 REMASTER。 这 种 技术 的 出 发 点 是 十 分 好 的 ， 在 一 个 设计 良好 的 系统 中 ， 或 者 
在 一 个 负载 并 不 是 很 高 的 多 实例 系统 中 ，DRM 能 够 发 挥 很 好 的 作用 。 很 多 从 % 升级 到 10g 的 系 
Ht. 升级 后 都 发 现 RACINTERCONNECT 的 流量 以 及 GES/GCS 的 相关 指标 都 有 所 改善 。 不 过 对 
于 一 些 比 较 繁忙 、 写 操作 很 多 的 系统 ，DRM 技术 可 能 导致 很 多 的 问题 。 比 如 说 ， 节 点 启动 时 
RECOVERY 的 性 能 大 幅度 下 降 ，OPEN 数据 库 很 慢 ， 或 者 在 一 个 错误 节点 上 执行 了 一 个 大 批量 
数据 修改 操作 时 ， 大 量 的 REMASTER 可 能 导致 系统 短暂 HANG 住 。 

多 实例 数据 库 的 特性 对 于 DBA 分 析 数 据 库 故 障 , 以 及 进行 优化 处 理 都 提出 了 一 个 新 的 要 求 。 
就 是 我 们 在 分 析 某 个 事件 或 者 问题 时 , 不 能 局 限于 某 个 实例 ， 而 要 将 思路 拓宽 到 所 有 实例 。 比 如 
说 我 们 发 现 某 个 操作 被 HANG 住 时 ， 不 仅仅 要 分 析 本 实例 上 面 可 能 存在 的 BLOCKER, mH 
将 分 析 的 范围 扩大 到 其 他 所 有 的 实例 ， 才 有 可 能 找到 问题 的 根源 。 

为 了 实现 多 实例 数据 库 技术 ，Oracle 的 很 多 组 件 都 带 有 实例 特性 。Oracle 的 所 有 数据 文件 都 
是 所 有 实例 共享 的 ， 一 般 来 说 必须 将 数据 文件 存放 在 所 有 实例 都 可 以 访问 的 存储 系统 上 。 有 些 
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DBA 就 可 能 有 疑问 了 ， 如 果 某 个 数据 文件 ， 只 有 某 个 实例 才 会 去 访问 〈 比如 这 个 数据 文件 相关 
的 表 空 间 上 的 表 , 被 限制 为 只 在 某 个 实例 上 访问 ), 那 么 这 个 文件 也 必须 要 在 所 有 节点 上 共享 吗 ? 
回答 当然 是 肯定 的 。 虽然 说 在 正常 情况 下 ,只 有 某 个 节点 才 会 访问 这 个 数据 文件 , 但 是 一 旦 这 个 
实例 容 了 ， 其 他 节点 要 替 这 个 节点 做 RECOVERY 的 时 候 ， 这 个 文件 就 必须 被 其 他 节点 访问 了 。 
在 维护 RAC 数据 库 的 时 候 ，DBA 经 常会 犯 的 一 个 错误 就 是 在 添加 裸 设备 的 时 候 , 往往 只 注意 了 
在 要 添加 的 节点 上 修改 文件 的 OWNER 属性 , 而 忘记 了 在 其 他 节点 上 修改 属性 。 一 旦 其 他 节点 读 
取 了 这 个 文件 ， 发 现 这 个 文件 无 法 访问 ， 那 么 在 其 他 节点 的 SGA 中 ， 这 个 文件 就 变 成 无 法 访问 
了 。 这 个 时 候 哪 怕 我 们 修改 了 文件 属性 , 在 SGA 中 的 文件 状态 还 是 无 法 改变 的 。 有 的 DBA 想 通 
过 设置 文件 OFFLINE/ONLINE 来 解决 这 个 问题 , 不 过 这 个 办 法 好 像 也 是 无 效 的 。 对 于 这 个 问题 ， 
Oracle 官方 建议 一 般 是 重启 其 他 的 几 个 实例 ,但 是 在 一 个 24 x 7 的 生产 系统 中 , 重启 实例 是 灾难 
性 的 ， 这 种 情况 下 执行 一 下 ALTER SYSTEM CHECK DATAFILES: 可 以 让 实例 重新 校 验 所 有 
ONLINE 文件 的 状态 ， 恢 复 文件 的 可 用 性 。 

多 实例 的 数据 库 中 ， 每 个 实例 拥有 一 组 独立 的 在 线 日 志 记 录 ， 也 就 是 我 们 常 说 的 REDO 
THREAD。 每 个 实例 独立 生成 在 线 日 志 信息 ， 并 且 拥 有 独立 的 LGWR 进程 用 于 写 入 在线 日 志文 
件 。 但 是 在 RAC 数据 库 环 境 中 ， 在 线 日 志文 件 也 必须 是 所 有 节点 都 能 够 共同 访问 的 。 原 因 也 是 
一 样 的 ， 当 进行 实例 恢复 的 时 候 ， 由 于 相关 的 数据 被 写 在 多 个 在 线 日 志文 件 中 ,因此 必须 用 到 所 
有 的 REDO LOG THREAD 中 的 在 线 日 志文 件 ， 才 能 够 完成 恢复 。 当 我 们 在 数据 库 上 增加 一 个 新 
的 实例 的 时 候 ， 必 须 为 这 个 实例 创建 一 组 新 的 在 线 日 志 记 录 ， 同 时 激活 这 个 REDO LOG 
THREAD。 反 过 来 ， 要 从 数据 库 中 删除 一 个 实例 的 时 候 ， 我 们 必须 关闭 这 个 THREAD， 否 则 无 
论 这 个 实例 是 否 被 使 用 ， 数 据 库 恢复 的 时 候 ， 仍 然 会 需要 使 用 这 个 THREAD 的 日 志 。 在 这 种 情 
况 下 关闭 某 个 THREAD 后 重新 做 一 次 全 库 备份 , 会 少 很 多 麻烦 事 。 如 果 你 真 的 碰 到 了 这 种 情况 ， 
而 那个 实例 的 在 线 日 志文 件 还 没 删除 , 那么 可 以 找 找 数 据 库 恢 复 所 需要 的 CHANGE# 是 否 在 在 线 
日 志 中 存在 ， 如 果 存 在 ， 你 也 可 以 直接 恢复 这 个 在 线 日 志 来 解决 这 个 问题 。 

在 使 用 UNDO 自动 管理 的 模式 下 ， 每 个 实例 都 需要 使 用 独立 的 UNDO 表 空 间 ， 这 些 表 空 间 
的 数据 文件 也 必须 存放 在 所 有 实例 都 能 够 访问 的 共享 存储 上 ， 其 原因 我 们 在 前 面 已 经 多 次 提 到 ， 
不 再 重复 了 。 

在 多 实例 数据 库 环 境 中 , 临时 表 空 间 是 可 以 多 个 实例 共享 的 , 不 过 能 够 共享 的 仅仅 是 临时 表 
空间 ， 临 时段 是 不 能 共享 的 。 在 一 个 临时 表 空 间 上 ， 每 个 实例 必须 拥有 自己 独立 的 临时 段 。 当 临 
时 表 空 间 满 的 时 候 ， 如 果 其 他 实例 的 临时 段 有 空闲 空间 , 那么 这 个 实例 可 以 从 其 他 实例 的 临时 段 
中 偷 取 一 个 EXTENT， 用 于 扩展 自己 的 临时 段 。 


1.4 数据 库 后 台 进 程 


数据 库 的 进程 可 以 简单 地 分 为 前 台 进程 和 后 台 进 程 ,前 台 进程 是 Oracle 客户 端 访问 数据 库 而 
创建 的 影子 进程 , 后 台 进 程 是 维持 Oracle 数据 库 正常 运行 所 必需 的 。 本 节 我 们 将 探讨 各 类 数据 库 
进程 之 间 是 如 何 分 工 协作 ， 并 实现 高 效 访问 的 。 
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1.4.1 进程 结构 


进程 是 操作 系统 中 的 一 种 机 制 , 它 可 使 用 操作 系统 中 的 资源 完成 某 个 特定 的 任务 。 一 个 进程 
通常 有 其 专用 的 存储 区 和 特定 的 功能 。 Oracle 进程 体系 结构 的 设计 目的 是 尽 可 能 地 使 用 系统 的 资 
源 ， 使 访问 者 获得 最 大 的 吞吐 量 和 最 短 的 响应 时 间 。 

Oracle 实例 有 两 种 类 型 : 单 进 程 实例 和 多 进程 实例 。 单 进程 Oracle ( 又 称 单 用 户 Oracle ) 是 
一 种 数据 库 系 统 , 一 个 进程 执行 全 部 Oracle 代码 。Oracle 数据 库 和 用 户 应 用 程序 无 法 实现 进程 分 
离 ， 所 以 Oracle 代码 和 用 户 数据 库 应 用 程序 都 是 通过 单 进程 执行 。 

在 单 进程 环境 下 的 Oracle 实例 ， 仅 允许 一 个 用 户 存 取 ， 例 如 在 MS-DOS 上 运行 Oracle 。 

多 进程 Oracle 实例 ( 又 称 多 用 户 Oracle ) 使 用 多 个 进程 来 执行 Oracle 的 不 同 部 分 , 对 应 于 每 
一 个 连接 的 用 户 都 有 一 个 进程 。 

在 多 进程 系统 中 ， 进 程 分 为 两 类 : 用 户 进 程 (又 称 前 台 进 程 ) 和 Oracle 后 台 进 程 。 当 用 户 运 
行 一 个 应 用 程序 时 ， 如 PRO*C 程序 或 Oracle 工具 (如 SQL*Plus )， 系 统 会 为 用 户 运行 的 应 用 建 
立 一 个 用 户 进程 ， 该 进程 通过 某 种 方式 启动 一 个 服务 器 进程 (前 台 进 程 )， 用 于 处 理 连接 到 该 实 
例 的 用 户 进程 的 请 求 。 如 果 应 用 和 Oracle 在 同一 台 机 右上 运行 , 而 不 通过 网 络 , 那么 用 户 进程 和 
服务 器 进程 之 间 可 以 通过 BEQ 协议 通信 ， 从 而 降低 系统 开销 。 然 而 ， 当 应 用 和 Oracle 运行 在 不 
同 的 机 器 上 时 ， 用 户 进程 使 用 TCP/IP 协议 ， 通 过 服务 器 进程 访问 Oracle， 可 执行 下 列 任务 。 
口 对 应 用 所 发 出 的 SQL 语句 进行 语法 分 析 和 执行 。 
а 从 磁盘 (数据 文件 ) 中 读 入 必要 的 数据 块 到 SGA 的 共享 数据 库 缓冲 区 ( 该 块 不 在 缓冲 区 
时 )。 
口 将 结果 返回 给 应 用 程序 处 理 。 

为 了 使 系统 性 能 最 好 并 能 够 协调 多 个 用 户 , 多 进程 系统 使 用 了 一 些 附加 进程 , 称 为 后 台 进 程 。 
在 许多 操作 系统 中 , 后 台 进程 是 在 实例 启动 时 自动 建立 的 。 一 个 Oracle 实例 可 以 包含 许多 后 台 进 
程 ， 但 它们 不 是 一 直 存 在 的 。 后 台 进 程 的 名 称 为 : 
口 DBWR， 数 据 库 写 人 程序 ; 
口 LGWR, 日 志 写 入 程序 ; 
О CKPT, 检查 点 ，; 
о SMON ， 系 统 监控 ; 
口 PMON， 进 程 监控 ; 
口 ARCH， 归 档 ; 
О RECO, Ve; 
О LCKn, fj; 
О Dnnn， 调 度 进程 ; 
О Snnn， 服 务 器 。 

每 个 后 台 进 程 与 Oracle 数据 库 的 不 同 组 件 进行 交互 ， 完 成 特定 的 功能 。 比 如 ，DBWR 负责 
脏 数据 存盘 工作 ，LGWR 负责 将 LOG BUFFER 中 的 数据 写 人 在 线 日 志文 件 。 
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1.4.2 ”后台 进程 的 功能 作 介绍 


Oracle 的 后 台 进 程 负责 管理 和 维护 Oracle 实例 。 每 个 后 台 进程 都 负责 一 项 独立 的 工作 。 这 些 
后 台 进 程 互 相 协作 , 完成 Oracle 的 公共 职能 。 它们 之 间 会 互相 监控 , 一 且 发 现 核心 的 后 台 进 程 出 
现 异 常 ， 会 主动 关闭 实例 。 下 面 依次 介绍 主要 后 台 进 程 的 功能 。 

1. DBWR 进程 

DBWR 进程 执行 将 数据 块 缓冲 区 写 和 人 数据 文件 的 工作 ,是 负责 缓冲 存储 区 管理 的 一 个 Oracle 
后 台 进 程 。 在 修改 DB Cache 中 的 某 个 缓冲 区 时 ， 会 将 它 标志 为 “DIRTY”，DBWR 的 主要 任务 
是 将 这 些 标 为 “DIRTY” 的 缓冲 区 写 和 磁盘， 使 缓冲 区 保持 “CLEAN”。 由 于 缓冲 区 填 和 人 数据 库 
或 被 用 户 进程 弄 脏 , 未 用 的 缓冲 区 数目 会 减少 , 最 终 可 能 导致 用 户 进程 从 磁盘 读 和 人 块 到 内 存 存 储 
区 时 无 法 找到 未 用 的 缓冲 区 。DBWR 将 管理 缓冲 存储 区 ， 使 用 户 进程 总 能 得 到 未 用 的 缓冲 区 。 

Oracle KH] LRU 算法 (最 近 最 少 使 用 算法 ) 保 持 内 存 中 的 数据 块 是 最 近 使 用 的 , 使 VO 最 小 。 
下 列 情况 预示 DBWR 要 将 弄 脏 的 缓冲 区 写 和 磁盘。 

а 当 服务 器 进程 将 一 缓冲 区 移 人 “DIRTY” 链 ， 此 “DIRTY” 链 达到 临界 长 度 时 ， 该 服务 器 
进程 将 通知 DBWR 进行 写 人 操作 。 这 个 临界 长 度 是 数据 库 隐 含 参数 DB BLOCK. WRITE 
BATCH 值 的 一 半 。 

о 服务 器 进程 在 LRU 表 中 查找 可 用 的 数据 块 缓冲 时 ， 如 果 在 查找 了 参数 _DB_BLOCK_ 
MAX SCAN СМТ 所 定义 数量 的 缓冲 区 后 ， 仍 没有 查 到 未 用 的 缓冲 区 ， 那 么 它 将 会 停止 
查找 ， 并 通知 DBWR 进行 数据 写 和 信 。DBWR 每 次 休眠 时 都 会 设置 定时 器 ， 如 果 出 现 超时 
(每 次 3 秒 ) DBWR 将 通知 自身 。 当 出 现 检查 点 时 , LGWR 将 通知 DBWR 进行 写 人 操作 。 
在 前 两 种 情况 下 ，DBWR 将 “DIRTY” 链 中 的 块 写 人 磁盘 ， 每 次 可 写 的 块 数 由 初始 化 参 
数 DB BLOCK. WRITE BATCH 所 指定 。 如 果 “DIRTY” 链 中 没有 该 参数 指定 块 数 的 组 
冲 区 ，DBWR 将 从 LRU 表 中 查找 另外 一 个 “DIRTY” 缓 冲 区 。 

о 如 果 DBWR 在 3 秒 内 未 活动 ， 则 出 现 超时 。 在 这 种 情况 下 ，DBWR 对 LRU 表 查 找 指定 数 
目的 缓冲 区 ， 将 所 找到 的 任何 和 弄 脏 的 缓冲 区 写 人 磁盘 。 每 当 出 现 超 时 ，DBWR 就 查找 一 个 
新 的 缓冲 区 组 。 每 次 由 DBWR 查找 的 缓冲 区 的 数目 是 隐 含 参数 _ DB_BLOCK_WRITE_ 
BATCH 值 的 两 倍 。 如 果 数 据 库 空运 转 ， 最 终 DBWR 会 将 全 部 缓冲 区 存储 区 写 人 磁盘 。 

口 在 出 现 检查 点 时 ，LGWR 指定 一 修改 缓冲 区 表 必 须 写 人 到 磁盘 ,而 DBWR 负责 将 指定 的 
缓冲 区 写 入 磁盘 。 

在 某 些 平台 上 ， 如 果 有 多 个 CPU， 那 么 一 个 实例 可 设置 多 个 DBWR。 在 这 样 的 实例 中 ,DB 
Cache 被 分 为 多 个 区 ， 每 个 DBWR 管理 一 个 或 者 几 个 DB Cache 分 区 。 这 种 结构 可 以 让 一 些 数据 
块 写 人 一 个 磁盘 ， 男 一 些 数据 块 写 入 其 他 磁盘 ， 从 而 提升 并 发 写 人 的 性 能 。 参 数 DB WRITERS 
可 以 控制 DBWR 进程 的 个 数 。 

2. LGWR 进程 

LGWR 进程 是 负责 管理 日 志 绥 冲 区 的 一 个 Oracle HAE, EKA RK А EW 
日 志文 件 。LGWR 进程 将 自 上 次 写 人 磁盘 以 来 的 全 部 REDO LOG ENTRY 5 Л 9] REDO LOG X 


14 数据 库 后 台 进 程 21 


件 中 。 触 发 LGWR 写 操作 的 条 件 如 下 。 
о 当 用 户 进 程 提交 一 事务 时 写 人 一 个 提交 记录 。 
а 每 3 秒 将 日 志 绥 冲 区 输出 。 
о 当日 志 缓 冲 区 的 已 满 13 时 ,将 日 志 缓 冲 区 输出 。 
о 当 DBWR 将 修改 缓冲 区 写 入 磁盘 时 ， 则 将 日 志 缓 冲 区 输出 。 
口 当 log buffer 达到 1MB 时 。 

LGWR 进程 同步 地 写 人 到 活动 的 镜 象 在 线 日 志文 件 组 。 如 果 组 中 一 个 文件 被 删除 或 不 可 用 ， 
LGWR 可 继续 地 写 和 该 组 的 其 他 文件 ， 而 数据 库 实 例 可 以 继续 运行 。 

日 志 缓 冲 区 是 一 个 循环 缓冲 区 。 当 LGWR 将 日 志 缓 冲 区 的 日 志 项 写 和 日志 文件 后 ， 服 务 器 
进程 即 可 将 新 的 日 志 项 写 和 人 到 该 日 志 缓冲 区 。LGWR 的 写 人 速度 很 快 , 以 确保 日 志 缓 冲 区 总 有 空 
间 可 写 入 新 的 日 志 项 。 


注意 ” 当 需 要 更 多 的 日 志 缓 冲 区 时 ，LWGR 会 在 一 个 事务 提交 前 就 将 日 志 项 写 出 ， 而 这 些 日 志 
项 仅 当 后 续 事务 提交 后 才 永 久 化 。 


Oracle 使 用 快速 提交 机 制 ， 当 用 户 发 出 COMMIT 语句 时 , 一 条 COMMIT 记录 立即 被 放 人 日 
志 绥 冲 区 ,但 相应 的 数据 缓冲 区 改变 被 延迟 ,直到 更 有 效 时 才 将 它们 写 和 人 数据 文件 。 提 交 时 ,将 
事务 赋 给 一 个 系统 变更 号 ( SCN )， 它 同事 务 日 志 项 一 起 被 记录 在 日 志 中 。 

3. CKPT 进程 

CKPT 进程 在 检查 点 出 现时 ， 对 全 部 数据 文件 的 文件 头 进行 修改 ， 并 在 控制 文件 中 记录 该 
检查 点 。 在 早期 版 本 中 ， 该 任务 由 LGWR 执行 。 然 而 ， 在 检查 点 明显 地 降低 系统 性 能 时 ， 可 
使 CKPT 进程 运行 ,将 原来 由 LGWR 进程 执行 的 检查 点 的 工作 分 离 出 来 , 由 CKPT 进程 执行 。 
从 Oracle 8 开始 ，CKPT 进程 被 独立 出 来 ， 它 不 再 将 块 写 人 磁盘 ， 该 工作 转 由 DBWR 完成 。 在 
Oracle 7 中 ， 可 以 通过 初始 化 参数 CHECKPOINT_PROCESS 来 控制 是 否 启 用 CKPT 进程 协助 
LGWR, 它 的 默认 值 是 FALSE; 另外 ,如果 数据 文件 的 数量 很 多 , 那么 启用 CKPT 会 对 性 能 
一 定 的 提升 。 

4. SMON 进程 

SMON 进程 负责 在 实例 启动 时 执行 实例 恢复 , 并 清理 不 再 使 用 的 临时 段 。 在 具有 并 行 服务 器 
选项 的 环境 下 ，SMON 对 有 故障 的 CPU 或 实例 进行 实例 恢复 。 从 Oracle 9i 开始 ， 事 务 回 滚 操作 
的 默认 行为 也 是 由 SMON 来 负责 处 理 的 。 虽 然 SMON 本 身 不 做 恢复 操作 ， 而 是 启用 并 行进 程 来 
处 理 , 但 是 它 起 到 整体 协调 的 作用 。SMON 进程 有 规律 地 被 唤醒 ,并 检查 是 否 有 工作 要 完成 ,如 
有 和 需要， 就 做 相应 的 处 理 ， 否 则 继续 休 虐 。 

5. PMON 进程 

PMON 进程 在 用 户 进 程 出 现 故 障 时 执行 进程 恢复 ,负责 清理 存储 区 和 释放 该 进程 所 使 用 的 资 
源 。 比 如 ， 某 个 进程 死 控 了 ，PMON 要 重 置 活动 事务 表 的 状态 ， 释 放 锁 资源 ， 将 该 故障 的 进程 ID 
从 活动 进程 表 中 移 去 。PMON 还 周期 性 地 检查 调度 进程 (DISPATCHER ) 和 服务 器 进程 的 状态 ， 如 
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果 发 现 这 些 后 台 进 程 死 掉 ,就 需要 重新 启动 。 PMON 有 规律 地 被 呼 醒 , 检查 是 否 有 需要 完成 的 工作 。 

6. RECO 进程 

RECO 进程 是 启用 分 布 式 选 项 时 才 会 存在 的 进程 , 而 且 DISTRIBUTED. TRANSACTIONS 参 
数 大 于 0。 当然 ， 分 布 式 事务 在 绝 大 多 数 系统 中 是 默认 安装 的 ， 因 此 一 般 来 说 ， 总 是 能 在 数据 库 
实例 中 看 到 这 个 进程 。RECO 进程 能 够 自动 解决 分 布 式 事务 中 的 故障 。 一 个 节点 的 RECO 后 台 进 
程 能 够 自动 连接 到 包含 错误 的 分 布 式 事务 的 其 他 数据 库 中 , 在 解决 了 所 有 的 故障 后 , 将 这 个 全 局 
事务 从 dba_2pc_pending 等 相关 的 表 中 删除 。 

当 数据 库 服务 器 的 RECO 后 台 进 程 试 图 同一 远程 服务 器 建立 通信 时 ， 如 果 远 程 服务 器 不 可 
用 ， 或 者 网 络 连接 不 能 建立 ，RECO 将 在 一 定时 间 间 隔 后 自动 重 连 。 

7. ARCH 进程 

ARCH 进程 将 已 填 满 的 在 线 日 志文 件 复制 到 指定 的 存储 设备 。 当 数据 库 的 日 志 模 式 为 
ARCHIVELOG 模式 并 可 自动 归档 时 ，ARCH 进程 才 存 在 。 

8. LCKn 进程 

LCKn 进程 在 具有 并 行 服务 器 选 件 的 环境 下 使 用 ， 可 多 至 10 个 进程 (LCK0, LCK1, +, 
LCK9 )， 用 于 实例 间 的 封锁 。 

9. Don 进程 〈 调 度 进 程 ) 

Dnnn 进程 允许 用 户 进程 共享 有 限 的 服务 器 进程 (SERVER PROCESS )。 没 有 调度 进程 时 ， 
每 个 用 户 进 程 需要 一 个 专用 服务 进程 (DEDICATED SERVER PROCESS )。 多 线索 服务 器 
(MULTI-THREADED SERVER ) 可 支持 多 个 用 户 进程 。 如 果 系 统 具 有 大 量 用 户 ， 多 线索 服务 器 
可 以 很 好 地 支持 ， 尤 其 在 客户 /服务 器 环境 中 。 

在 一 个 数据 库 实 例 中 可 建立 多 个 调度 进程 。 对 每 种 网 络 协议 至 少 建立 一 个 调度 进程 。 数 据 库 
管理 员 根据 操作 系统 中 每 个 进程 可 连接 数目 的 限制 决定 启动 的 调度 程序 的 最 优 数 , 在 实例 运行 时 
增加 或 删除 调度 进程 。 多 线索 服务 器 需要 SQL*Net 版 本 2 或 更 高 的 版 本 。 在 多 线索 服务 器 的 
置 下 ,一 个 网 络 接收 器 进程 等 待 客户 应 用 连接 请 求 ,并 将 每 一 个 发 送 到 一 个 调度 进程 。 如 果 不 
能 将 客户 应 用 连接 到 一 调度 进程 时 ,网 络 接收 器 进程 将 启动 一 个 专用 服务 器 进程 , 该 网 络 接收 器 
进程 不 是 Oracle 实例 的 组 成 部 分 ， 而 是 处 理 与 Oracle 有 关 的 网 络 进程 的 组 成 部 分 。 在 实例 启动 
时 , 该 网 络 接收 器 被 打开 ,为 用 户 连接 到 Oracle 建立 一 通信 路 径 , 然后 每 一 个 调度 进程 把 连接 请 
求 的 调度 进程 的 地 址 传 给 它 的 接收 器 。 当 一 个 用 户 进 程 作 连接 请 求 时 ,网 络 接收 器 进程 分 析 请 求 
并 决定 该 用 户 是 否 可 使 用 一 调度 进程 。 如 果 是 , 该 网 络 接收 器 进程 返回 该 调度 进程 的 地 址 , 之 后 
用 户 进程 直接 连接 到 该 调度 进程 。 有 些 用 户 进程 不 能 调度 进程 通信 ( 如果 使 用 SQL*Net 以 前 的 
版 本 )， 网 络 接收 需 进 程 不 能 将 此 类 用 户 连 接 到 一 调度 进程 。 在 这 种 情况 下 ， 网 络 接收 器 将 建立 
一 个 专用 服务 器 进程 和 一 种 合适 的 连接 。 


m = 


1.4.3 ”哪些 后 台 进 程 可 以 杀 
在 很 多 情况 下 我 们 需要 杀 死 后 台 进 程 。 比 如 ， 系 统 出 现 了 大 量 挂 起 的 现象 ， 而 通过 
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HANGANALYZE 工具 分 析 ， 我们 发 现 元 凶 是 一 个 后 台 进 程 ， 那 么 是 否 要 通过 杀 掉 这 个 进程 来 解 
决 问题 ， 就 要 十 分 谨慎 了 。 因 为 有 些 后 台 进 程 是 不 能 随便 杀 的 ,一旦 杀 掉 就 可 能 导致 数据 库 实 例 
Hj. BU, AX’ DBA 给 自己 定 了 一 条 金 科 玉 律 ， 就 是 后 台 进 程 绝对 是 不 能 杀 的 。 

其 实 这 种 做 法 过 于 保守 了 ,只 要 你 足够 了 解 后 台 进程 的 主要 功能 , 就 可 以 十 分 安全 地 管理 后 
台 进 程 了 。 本 节 老 白 将 以 Oracle 10g 和 11g 为 例 ， 和 大 家 讨论 究竟 哪些 后 台 进 程 是 可 以 杀 的 。 

首先 我 们 来 看 六 大 核心 进程 。 其 实 Oracle 并 没有 核心 进程 这 个 概念 , 这 是 老 白 自己 的 归纳 总 
结 。 那 么 哪 几 个 后 台 进 程 可 以 称 为 六 大 核心 进程 呢 ?pmon、smon、dbwr、lgwr、reco 和 ckpt 这 
六 个 进程 是 所 有 Oracle 数据 库 必 不 可 少 的 ， 其 中 ckpt 进程 出 现 得 较 晚 ， 其 他 五 个 进程 是 老 白 使 
用 Oracle 数据 库 以 来 就 一 直 存 在 的 系统 进程 。 这 些 进 程 无 论 哪个 出 现 故 障 , 都 会 导致 数据 库 实 例 
崩 演 。 因 此 ， 这 些 进程 是 无 论 如 何 都 不 能 杀 的 。 如 果 我 们 杀 掉 其 中 某 个 进程 ,在 ALERT LOG 中 
就 会 发 现 各 种 错误 。 

在 某 个 shell F, AH ckpt 进程 : 


[oracle@localhost ~]$ ps -ef|grep ckpt 


grid 5245 1 0 Sep25 ? 00:00:00 asm_ckpt_+ASM 
oracle 5377 1 0 Sep25 ? 00:00:22 ora ckpt orcl 
oracle 10891 10763 0 08:48 pts/4 00:00:00 grep ckpt 


[oracle@localhost ~]$ kill -9 5377 
执行 了 上 述 命令 后 ， 我 们 发 现 ALERT LOG 中 出 现 了 : 


Mon Sep 26 08:48:31 2011 

System state dump requested by (Instance-1, osid-5342 (PMON)), summary-[abnormal 
Instance termination]. 

System State dumped to trace file 
/u01/app/oracle/diag/RDBMS/orcl/orcl/trace/orcl diag 5365.trc 

Mon Sep 26 08:48:32 2011 

PMON (ospid: 5342): terminating the Instance due to error 469 

Mon Sep 26 08:48:32 2011 

ORA-1092 : opitsk aborting process 

Dumping diagnostic data in directory-[cdmp 20110926084831], requested by (Instance=1, 
osid-5342 (PMON)), summary-[abnormal Instance termination]. 

Instance terminated by PMON, pid - 5342 


可 以 看 到 ， 由 于 ckpt 出 现 故障 ，pmon 进程 将 实例 关闭 了 。 如 果 杀 掉 pmon 又 会 出 现 什么 情 
况 呢 ? 

Mon Sep 26 08:52:58 2011 

Shutting down Instance (abort) 

License high water mark = 4 

USER (ospid: 11224): terminating the Instance 

Instance terminated by USER, pid = 11224 

Mon Sep 26 08:52:59 2011 

Instance shutdown complete 

我 们 看 到 , 当 pmon 被 杀 掉 后 ,一 个 前 台 进 程 执 行 了 shutdown abort 操作 ,终结 了 实例 (Instance 
terminated by User )。 可 以 看 出 ， 昌 然 pmon 是 监控 进程 的 后 台 进 程 ， 但 是 一 旦 重要 的 后 台 进 程 出 
现 故障 ，pmon 会 自动 关闭 实例 。 反 过 来 所 有 的 Oracle 进程 ， 包 括 前 台 进 程 和 后 台 进 程 ， 也 在 监 
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视 pmon， 一 旦 发 现 pmon 异常 ， 会 立即 关闭 实例 。 这 种 相互 监控 的 机 制 也 是 大 型 系统 中 最 为 常 
用 的 方法 。 

下 面 我 们 来 看 看 10g 新 增加 的 MMAN 进程 ，MMAN (Memory Manager ) 进程 是 10g 新 引 
人 的 进程 ， 主 要 目的 是 实现 共享 内 存 自动 管理 的 功能 ， 自 动 调整 共享 内 存 各 个 组 件 的 大 小 。 


Mon Sep 26 11:09:52 2011 

Errors in file /opt/oracle/admin/orcl/bdump/orcl pmon 6261.trc: 
ORA- 00822: MMAN process terminated with error 

Mon Sep 26 11:09:52 2011 

PMON: terminating Instance due to error 822 

Instance terminated by PMON, pid = 6261 


可 以 看 到 ， 一 旦 MMAN 进程 出 现 故 障 ， 数 据 库 实例 就 会 月 演 。 看 样子 MMAN 是 继 六 大 核 
心 进程 之 后 的 第 七 个 不 可 杀 的 核心 进程 。 

PSPO 进程 在 10g 中 开始 引入 ， 主 要 功能 是 启动 其 他 的 Oracle 进程 。 这 个 进程 也 是 一 个 十 分 
关键 的 核心 进程 ,一旦 出 现 问题 ， 将 导致 数据 库 实例 故障 。 


Errors in file /opt/oracle/admin/orcl/bdump/orc| pmon 32149.trc: 
ORA- 00490: PSP process terminated with error 

Mon Sep 26 14:14:55 2011 

PMON: terminating Instance due to error 490 

Instance terminated by PMON, pid = 32149 


至 此 ， 我 们 已 经 看 到 了 八 个 关键 核心 进 

下 面 我 们 来 看 一 下 cjq0 进程 。 шы EFE, ATEM job$ 表 中 找到 需要 执 
行 的 任务 ， 并 分 配 job 进程 执行 ， 如 果 job 会 自 om job 进程 (在 
job queue processes 参数 限制 范围 内 )。 下 面 来 看 看 杀 掉 这 个 进程 会 有 什么 结 


Mon Sep 26 09:07:18 2011 

Restarting dead background process CJQ0 
Mon Sep 26 09:07:18 2011 

С) 00 started with рі dz25, OS id=12226 


可 以 看 出 cjq0 HERR, сја 进程 会 被 重启 。 

既然 cjq0 都 可 以 杀 ， 那 么 cjq0 产生 的 JXXX 用 做 实验 了 ， 肯 定 是 能 杀 的 了 。 
其 实 老 白 也 是 经 常 杀 掉 JOB 进程 的 ， 在 某 些 系统 中 ， 经 常会 有 一 些 JOB 进程 占用 大 量 的 系统 资 
源 ， 从 而 导致 数据 库 性 能 问题 。 这 时 , 为 了 恢复 OLTP 应 用 的 性 能 ， 杀 掉 JOB 进程 是 最 简单 的 方 
法 。 不 过 在 杀 掉 JOB 进程 之 前 一 定 要 做 仔细 的 分 析 ， 如 果 JOB 进程 中 正在 做 一 个 数据 量 很 大 的 
大 型 修改 事务 , 那么 杀 掉 这 个 JOB, 可 能 会 导致 大 量 的 回 滚 操作 ， 从 而 对 系统 性 能 产生 更 为 不 利 
的 影响 。 

下 一 个 我 们 要 来 研究 的 是 arch 进程 ， 在 Oracle 10g "P, arch 进程 一 般 是 arc0, arc1 ，…。 我 们 
来 杀 掉 一 个 arch 进程 ， 看 看 会 有 什么 结果 。 


Mon Sep 26 09:56:27 2011 

ARCH: Detected ARCH process failure 
ARCH: STARTING ARCH PROCESSES 

ARCO: Archival started 
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ARCH: STARTING ARCH PROCESSES COMPLETE 
ARCO started with pidz16, OS id=6646 
ARCO: Becoming the 'no FAL' ARCH 

ARCO: Becoming the 'no SRL' ARCH 


可 以 看 出 ，arc0 进程 被 杀 掉 后 , 会 自动 重启 ,而 数据 库 实例 没有 发 生 故 障 。 因 此 arch 进程 如 
果 出 现 故 障 ， 在 必要 情况 下 ， 我们 是 可 以 杀 掉 该 进程 的 。 

下 面 我 们 来 看 一 下 CJQ0 进程 ，CJQ0 进程 是 队列 监控 同步 进程 ( QMNC ) 和 队列 服务 进程 
( QXXX ) 的 统称 。 


Mon Sep 26 09:10:46 2011 

Restarting dead background process CJQ0O 
Mon Sep 26 09:10:46 2011 

С] 00 started with pid=25, 05 id=12347 


从 上 面 的 测试 可 以 看 出 ，CJQ0 进程 是 可 以 杀 的 ， 杀 掉 CIQO 进程 的 后 果 是 相关 进程 重启 。 
MMON 和 M000 是 Oracle 10g 引入 的 新 后 台 进程 , MMON 是 管理 监控 进程 ,M000 是 MMON 
的 SLAVE 进程 ， 协 助 MMON 进程 工作 。 如 果 这 些 进程 出 现 故 障 会 有 什么 结果 呢 ? 


Mon Sep 26 10:11:39 2011 
Restarting dead background process MMON 
MMON started with pid=11, OS id=11860 


MMON 进程 是 可 以 自动 重启 的 ， 当 然 也 在 可 杀 范 围 内 了 。 

类 似 的 MMNL 进程 也 是 AWR 新 增 的 进程 ， 主 要 作用 是 将 AWR 数据 从 内 存 中 刷新 到 表 中 。 
这 个 进程 如 果 被 杀 掉 也 是 可 以 自动 重启 的 。 在 这 里 我 们 就 不 一 一 列 出 实验 数据 了 : 

O DISPATCHER 进程 ОХХХ: 如 果 被 杀 掉 ，ALERT 会 报错 ， 不 会 导致 实例 宕 机 ， 根 据 需 要 

进行 重启 。 

а 共享 服务 进程 SXXX: 如 果 被 杀 掉 ， 不 会 导致 实例 宕 机 ， 根 据 需 要 进行 重启 。 

O 并 行进 程 PXXX/PZXX: 并 行进 程 ， 如 果 被 杀 掉 ， 不 会 导致 实例 宕 机 ， 进 程 根据 需要 进行 

重启 。 

口 高 级 队列 从 属 进程 ОХХХ: 如 果 被 杀 掉 ,不 会 导致 实例 宕 机 ， 进程 根据 需要 进行 重启 。 如 
果 存 在 高 级 队列 操作 ， 杀 掉 此 类 进程 要 十 分 慎重 。 

Oracle 10g 引 入 了 ASM 后 ， 也 新 增 了 一 些 和 ASM 有 关 的 进程 。 首 先 ASM 实例 具有 一 系列 
WEAH, HK, RDBMS 为 了 访问 ASM 也 新 增 了 一 系列 的 后 台 进 程 。 我 们 来 看 看 ASM 实例 
的 后 台 进 程 。 

ASM 实 例 也 拥有 类 似 RDBMS 实例 的 核心 进程 ,另外 ASM 实例 新 增 了 一 些 其 他 的 后 台 进 程 ， 
下 面 我 们 做 一 个 简单 的 了 解 。 

O ASMB: 当 数 据 库 实 例 使 用 SPFILE 时 启动 的 ASM 后 台 进 程 。 这 个 进程 是 十 分 关键 的 ， 

一 旦 出 现 故障 将 导致 ASM 实例 宕 机 。 

口 RBAL: DISKGROUP 做 rebalance 的 后 台 进 程 , 该 进程 一 旦 有 故障 将 导致 ASM 实例 宕 掉 。 

о DBW0: DB writes， 和 RDBMS 的 DB WRITER 类 似 ， 不 过 是 将 ASM CACHE 中 的 数据 
写 和 人 磁盘， 该 进程 一 旦 有 问题 将 导致 ASM 实例 故障 。 
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о SMON: 恢复 进程 ， 类 似 于 RDBMS 的 SMON 进程 ， 处 理 DISKGROUP 的 恢复 操作 ， 一 
旦 有 问题 将 导致 ASM 实例 故障 。 
口 CKPT: Checkpoint 进程 ， 类 似 于 RDBMS 的 CKPT 进程 ,一 旦 有 问题 将 导致 ASM 实例 
故障 。 
口 PSP0: 启动 其 他 ASM 实例 进程 的 进程 ,一 旦 有 问题 将 导致 ASM 实例 故障 。 
O GMON: 群 组 监控 进程 ， 用 于 节点 监控 和 状态 表 的 维护 ， 一旦 有 问题 将 导致 ASM 实例 
故障 。 
О ora ASMB: 特殊 的 ASM 前 台 进 程 。 
О КАТЕ: Konductor or ASM Temporary Errands ， 用 来 执行 ONLINE 磁盘 的 临时 任务 进程 。 
O VKTM: 管理 快速 计时 需 的 进程 。 
口 PING: 计量 网 络 延 时 的 进程 。 
口 DIA?: 类 似 于 数据 库 的 diag 进程 。 
口 DIAG: 类 似 于 数据 库 的 diag 进程 。 
О LGWR: Log writer, 和 数据 库 类 似 ， 人 处 理 磁盘 组 的 REDO 信息 。 
OLMON: 锁 监 控 进 程 ， 类 似 于 数据 库 的 LMON 进程 。 
口 LMS?: 锁 监控 SLAVE 进程 ， 类 似 于 数据 库 的 LMS 进程 。 
口 MMAN: SGA 自动 调整 进程 ， 类 似 于 数据 库 的 MMAN。 
O 6777: 用 于 离线 磁盘 的 SLAVE 进程 。 
О х777: 人 磁盘 组 重 配置 后 删除 磁盘 的 SALVE 进程 。 
О pz? 用 于 GLOBAL VIEW 查询 的 并 行 SLAVE 进程 。 

Oracle 11g 在 后 台 进 程 方面 有 了 较 多 的 改变 ， 这 种 改变 有 时 候 甚 至 让 我 们 感觉 Oracle 数据 库 
变 陌 生 了 ， 需 要 重新 认识 Oracle 11е 的 后 台 进 程 结构 。 下 面 是 新 增 的 后 台 进 程 。 
口 ACMS (atomic controlfile to memory service )， 这 是 每 个 实例 都 有 的 代理 进程 ， 在 ВАС 环 
境 下 ， 对 控制 进程 事务 的 提交 和 回 退 起 到 辅助 作用 。 
口 DBRM ( database resource manager )， 用 于 资源 管理 和 资源 计划 相关 的 任务 。 
О DIAO (diagnosability process 0 )， 目 前 只 有 “0”， 没 有 其 他 进程 ， 用 于 数据 库 的 挂 起 检测 
和 和 死 锁 处 理 。 
О DIAG ( diagnosability )， 进 行 诊断 DUMP， 执 行 全 局 oradebug 命令 。 
口 EMNC (event monitor coordinator )， 用 于 数据 库 事件 管理 和 发 布 的 进程 。 
О ЕВРА (flashback data archiver process )， 闪 回 区 归档 进程 ， 用 于 将 跟踪 表 的 历史 记录 写 入 
归档 日 志 ， 管理 内 回 数据 区 的 空间 。 
О GTXO-j (global transaction ), TE RAC 环境 中 为 XA 全 局 事务 提供 透明 的 服务 ， 只 在 RAC 
环境 中 出 现 。 系 统 会 根据 XA 事务 的 负载 情况 确定 启动 几 个 这 种 进程 。 
口 KATE， 当 磁盘 离线 时 代理 ASM metadata 的 IO。 
О MARK， 当 写 人 一 个 离线 磁盘 出 错时 记录 这 个 ALLOCATION UNIT 为 过 期 状态 。 
口 SMCO ( space management coordinator ), 执行 空间 管理 有 关 的 作业 ， 比 如 空间 预 分 配 和 空 
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间 回 收 。 可 以 动态 生成 Wnnn SLAVE 进程 。 [ 
О VKTM (virtual keeper of time )， 每 秒 更 新 一 次 时 间 ， 在 高 优先 级 情况 下 可 以 提供 20 毫秒 

的 基准 时 间 计 数 。 

о DSKM (slave diskmon )， 用 于 RDBMS #1 ASM 实例 之 间 的 联系 通道 。Master Diskmon < 

护 进程 处 理 IO 隔离 信息 ,IO 资源 管理 计划 将 Transaction Commit Cache 信息 传输 到 SAGE 

存储 , 也 用 来 在 节点 和 SAGE 存储 服务 器 之 间 实 现 skgxp ANT 协议 。 如果 没有 配置 SAGE 

存储 ，diskmon slave 进程 会 在 实例 启动 后 自动 关闭 。 


144 是 谁 在 执行 SQL 


“是 谁 在 执行 SQL? ”这 个 问题 看 似 很 简单 ， 不 过 要 认真 考虑 起 来 ， 却 也 不 那么 简单 。 很 多 
工作 了 7、8 年 的 DBA 可 能 还 真 的 没有 认真 考虑 过 这 个 问题 。 最 初 , 老 白 一 直 以 为 是 Oracle 的 后 
台 进 程 在 执行 SQL, 然后 将 执行 的 结果 返回 给 客户 端 进 程 。 直到 学 习 了 TWO TASK 这 个 概念 后 ， 
才 知 道 在 客户 端 连接 到 数据 库 时 ，Oracle 会 创建 一 个 服务 进程 ( Server Process ), Oracle 的 客户 端 
通过 和 该 进程 通信 来 完成 SQL 的 执行 。 

现在 回头 一 想 ， 如 果 是 Oracle 的 后 台 进 程 来 执行 SQL， 那 么 在 一 个 大 型 的 数据 库 系 统 中 ， 
会 有 数 千 甚 至 上 万 个 客户 端 在 访问 数据 库 ， 光 凭 几 个 Oracle 后 台 进 程 是 肯定 无 法 完成 这 个 任务 
的 ， 这 样 就 会 出 现 瓶 颈 。 从 这 个 角度 来 看 ， 服 务 进程 应 该 是 执行 SQL 的 “最 佳人 选 ” 了 。 在 独 
立 服务 器 模式 下 ， 每 个 Oracle 会 话 都 拥有 一 个 独立 的 服务 进程 ， 如 果 让 它 来 担当 执行 SQL 的 角 
E, 那么 就 不 会 出 现 资源 瓶颈 了 。 

EXE, Oracle 也 是 这 样 安排 的 , TWO TASK 的 服务 器 端的 服务 进程 , 担当 的 就 是 这 样 一 个 
角色 。 客 户 端 要 执行 的 SQL， 通过 SQL#Net 或 者 BEQ ( 客户 端 和 数据 库 服 务 器 运行 在 同一 台 服 
务 器 上 时 ， 可 以 不 通过 SQL*Net， 而 直接 通过 IPC 通信 协议 BEQ 来 通信 ) 发 送 给 服务 进程 ， 由 
它 来 完成 SQL 的 执行 。 

我 们 可 以 更 加 深入 地 理解 一 下 这 方面 的 概念 。 先 要 问 大 家 一 个 问题 ， 执 行 SQL 的 主体 是 什 
A? 可 能 很 多 DBA 会 觉得 有 些 迷 惑 了 ， 怎 么 什么 简单 的 问题 到 了 老 白 这 里 都 变 得 那么 不 确定 了 
WE? 执行 SQL 的 主体 是 会 话 (Session) Vf, PUT SQL 的 呼叫 是 由 会 话 发 起 的 ,会 话 是 Oracle 数 
据 库 用 户 进行 SQL 操作 的 唯一 渠道 。 

那么 下 一 个 问题 又 来 了 , 会 话 又 是 什么 呢 ? 搞 过 网 络 编程 的 朋友 可 能 早 就 听 说 过 会 话 这 个 概 
念 了 。 两 个 网 络 设备 要 进行 通信 ， 必须 先 建 立 起 一 个 会 话 ， 这 个 会 话 就 是 承载 所 有 通信 工作 的 逻 
辑 载体 。 再 往 前 追溯 , 会 话 的 概念 来 自 通信 行业 , 不 过 Oracle 会 话 的 本 质 更 类 似 于 网 络 设备 之 间 
的 通信 。 大 家 都 知道 网 络 通信 有 面向 连接 的 协议 , 也 有 面向 无 连接 的 协议 。 面 向 连接 的 协议 一 般 
适用 于 上 下 文 和 状态 十 分 关键 的 应 用 场合 。Oracle 的 会 话 正 是 具有 这 样 的 特征 ， 所 以 采用 面向 连 
接 的 通信 协议 ， 目 前 最 常用 的 就 是 TCP/P 协议 。 出 于 安全 考虑 ， 在 建立 会 话 之 初 ，Oracle 需要 
通过 安全 认证 , 这 也 就 是 我 们 常见 的 “数据 库 登 录 ”，Oracle 的 术语 称 为 LOGON。 在 LOGON 的 
时 候 ,首先 Oracle 客户 端 通过 SQL*Net 协议 或 者 BEQ 协议 创建 一 个 服务 进程 ,如 果 通 过 SQL*Net 
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协议 ， 客 户 端 首先 要 和 监听 器 通过 TCP/IP, SPX 等 面向 连接 的 网 络 协议 建立 通信 会 话 ， 由 监听 
器 创建 一 个 服务 进程 ,客户 端 进程 将 网 络 通信 会 话 重 定向 到 这 个 服务 进程 ,随后 ,客户 端 进程 和 
服务 进程 建立 通信 会 话 。 大 家 可 能 注意 到 了 ， 老 白 在 这 里 说 了 很 多 次 “通信 会 话 ”， 这 么 说 就 是 
为 了 区 别 与 Oracle 的 会 话 。 和 客户 端 通信 的 服务 进程 也 就 是 Oracle 术语 中 所 说 的 前 台 进 程 ， 客 
户 端 和 前 台 进 程 建立 了 通信 会 话 并 不 等 于 说 Oracle 的 会 话 已 经 建立 了 ,会 话 是 一 个 更 为 虚拟 的 概 
念 。 大 家 先 不 要 着 急 ， 等 老 白 一 步 一 步 地 进行 剖析 。 客 户 端 和 服务 进程 完成 通信 会 话 的 握手 后 ， 
首先 将 LOGON 所 需要 的 信息 发 送 给 前 人 台 进 程 。 前 台 进程 收 到 这 些 信息 后 ， 执 行 一 个 被 称 为 
LOGON 的 操作 , 校 验 用 户 和 权限 。 这 个 校 验 工作 可 以 有 多 种 方式 , 最 常见 的 是 通过 SYSTEM K 

空间 中 的 USER$ 表 中 保存 的 用 户 名 和 密码 进行 校 验 。Oracle 还 支持 其 他 方式 的 用 户 名 、 密 码 校 
验方 式 ， 比 如 操作 系统 校 验 、 外 部 安全 设备 校 验 (LDAP )。 完 成 LOGON 操作 后 ， 系 统 会 在 数据 
库 服务 器 的 SGA 中 创建 一 个 会 话 的 数据 结构 ， 这 个 数据 结构 被 称 为 SESSION STATE OBJECT, 
Oracle 内 部 数据 结构 为 ksuse。 在 《Oracle RAC 日 记 》 中 ， 老 白 曾 介绍 过 这 个 结构 ， 具 体 如 图 1-1 
所 示 。 


00000001 usr session (as opposed to recursive session 
00000002 recursive session (always internal) 

00000004 audit logon/logoff, used by cleanup 

00000008 ollback from plsq 

00000010 user session created by system processes 
00000020 whether UGA is allocated in sga 

00000040 whether user session logs on to ORACLE 
00000080 user 
00000100 
00000200 
00000400 se 
00000800 
00001000 
00002000 


sion cre ated by multi-stated server 
{defer} interrupt 

cense count decrement 
en detached 
duri ng shutdown normal 
т is cached 


8 eve serializable 
zable for READ COMMITTED 


00004000 ove 
STATE OBJECT 00008000 e scheduler 
00010000 SKiP unusable indexes maintenance 
00020000 defer all deferrable constraint by default 
= : Н 00040000 deferrable constraints are immediate 
type=4, session state obj 00080000 session to be implicitly detached 
00100000 tr tion audit logged 
00200000 So e checking in job q process enabled 
已 
指向 PROCESS STATE OBJ 00400000 sess s migratable 
00800000 migratable session need to get ownership id 
事件 SO 的 01000000 suppress/enable TDSCN ce amputations 
fr 的 地 址 02000000 parent of migratable s 
04000000 MV container upd og 
SID 08000000 ап NS alter sessic s done 


党 检测 [的 售 自 
用 于 死 锁 检测 的 信息 | | 10000000. A trusted cal lout was performed 
20000000 An HO Agent was called 
40000000 an alter session sel Lime zone was done 


80000000 Summary Refresh 


SO: c00000060b0$3f08, me 4, 
P :00000060b0067a8, flag: (51) USR/- BSY/-/-/-/-/- 
000000000, short-term DID: 0000-00000000 

txn branch: 0000000000000000 

oct: 0, prv: 0, sql: 0000000000000000, psql: 0090000000000000, user: 0/SYS 
waiting for 'gcs remote message’ blfcking sess=0x000 00000000 seq-54505 wait ^time-0 seconds since wait started-l 


waittime=18, poll=0, event= 


rary object counter: 0 


等 待 事件 及 历 rm Е SQL fil PL/SQL fy SO | 


图 1-1 


14 数据库 后 台 进 程 29 


图 1-1 显示 的 是 SESSION STATE OBJECT 的 信息 ， 这 个 信息 只 包含 了 会 话 的 基础 信息 ， 会 
话 相 关 的 数据 结构 十 分 复杂 ， 已 经 超出 了 本 书 的 讨论 范围 ， 因 此 不 做 更 多 的 描述 。 

会 话 建立 后 , 就 成 为 客户 进程 和 数据 库 实例 之 间 的 沟通 渠道 和 桥梁 , 执行 客户 端 对 数据 库 的 
TRE, 包括 执行 SQL。 不 过 会 话 是 一 个 逻辑 结构 ,必须 依赖 于 其 容器 一 一 服务 进程 ( 也 叫 前 台 进 
程 )。 在 独立 服务 器 模式 下 ， 每 个 会 话 对 应 一 个 独立 的 服务 进程 ，Oracle 也 提供 了 一 种 共享 服务 
器 模式 ， 在 这 种 模式 下 ， 一 个 服务 进程 可 以 为 多 个 会 话 服 务 ， 换 句 话 说， 一 个 服务 进程 可 以 成 为 
多 个 会 话 的 容器 。 

在 共享 服务 器 模式 下 ， 一 般 会 配 有 一 个 或 者 多 个 调度 进程 (DISPATCHER, ， 比 如 D000 ) 和 
一 组 服务 进程 ， 这 些 服务 进程 的 最 大 数量 受到 max shared servers 参数 控制 。 当 监听 进程 接收 到 
来 自 客户 端的 连接 请 求 时 ， 不 是 创建 独立 的 服务 进程 ， 而 是 使 用 现 有 的 服务 进程 池 来 提供 服务 。 
监听 进程 首先 会 和 调度 进程 通信 , 找到 可 用 的 服务 进程 ,调度 进程 会 将 这 个 服务 进程 及 其 通信 端 
口号 发 送 给 监听 进程 , 监听 进程 将 网 络 通信 连接 重 定向 到 这 个 服务 进程 , 完成 客户 端 和 服务 进程 
之 间 的 握手 。 

在 共享 服务 器 模式 下 ,由 于 多 个 会 话 共享 一 个 服务 进程 ,因此 服务 进程 作为 共享 资源 ， 也 可 
能 成 为 一 个 瓶颈 。 如 果 使 用 同一 个 服务 进程 的 几 个 共享 会 话 中 有 一 个 执行 了 时 间 很 长 、 开 销 很 大 
的 SQL, 那么 其 他 会 话 将 会 处 于 等 待 状态 。 共 享 服务 器 模式 在 早期 的 数据 库 系 统 中 的 使 用 是 比较 
广泛 的 ， 因 为 早期 的 服务 器 内 存 资源 有 限 ， 如 果 使 用 独立 服务 器 模式 ， 内 存 资源 将 会 十 分 紧张 ， 
而 使 用 共享 服务 器 模式 可 以 在 内 存 资源 有 限 的 情况 下 , 支持 大 量 的 数据 库 会 话 。 在 目前 内 存 资 源 
十 分 充裕 的 情况 下 ,共享 服务 器 模式 的 应 用 就 越 来 越 少 了 ,一 个 进程 为 一 个 会 话 服务 ， 可 以 有 效 
地 提高 系统 总 体 的 吞吐 能 力 。 

不 过 ,共享 服务 器 模式 也 并 不 是 完全 没有 了 用 武之 地 ,尤其 是 现在 服务 器 性 能 有 了 大 幅 提高 ， 
对 于 某 些 没有 使 用 连接 池 的 ， 以 短 连 接 为 主 的 应 用 来 说 ， 如 果 执 行 的 大 多 数 是 开销 较 小 的 SQL, 
那么 使 用 共享 服务 器 模式 可 以 避免 由 于 应 用 软件 使 用 短 连接 而 导致 的 数据 库 连 接 风暴 , 因为 这 种 
数据 库 连 接 避 免 了 频繁 启动 和 关闭 服务 进程 带 来 的 性 能 问题 。 

共享 服务 器 模式 还 用 于 数据 库 连 接 穿 透 NAT 防火 墙 。 我 们 经 常会 碰 到 这 样 的 应 用 场合 ， 客 
户 端 在 防火 墙 外 ， 而 服务 器 在 防火 墙 内 ， 出 于 安全 考虑 ， 数 据 库 服 务 器 的 服务 IP 3d NAT 解释 
为 外 网 的 耳 ， 提 供给 防火 墙 外 的 客户 端 使 用 。 不 过 SQL*Net 连接 在 穿 透 防火 墙 时 往往 会 出 现 问 
АЙ, FA SQL*Net 在 连接 时 首先 连接 监听 器 ， 然 后 由 LISTNER 分 配 一 个 服务 进程 ， 再 将 连接 重 
定向 到 服务 进程 。 正 是 这 种 重 定 向 操作 ， 会 导致 客户 端 出 现 “TNS-12535” 之 类 的 错误 。 为 了 解 
决 这 个 问题 ，Oracle 提供 了 一 个 技术 ,叫做 Connect Manager (CMAN ), CMAN 是 一 个 SQL*Net 
的 代理 。 当 外 网 的 客户 端 要 连接 数据 库 服 务 器 时 ， 首 先 不 连接 监听 ， 而 是 连接 CMAN, CMAN 
作为 代理 ， 接 受 客 户 端的 连接 ， 然 后 将 SQL*Net 包 进 行 转发 。 为 了 避免 连接 过 程 中 出 现 的 重 定 
向 问题 ，CMAN 采用 了 预先 连接 的 连接 池 技 术 ，CMAN 在 启动 时 就 建立 了 一 个 连接 池 ， 并 和 数 
据 库 的 服务 进程 建立 了 连接 。 因 此 客户 端 通过 CMAN 连接 数据 库 时 , 不 需要 建立 新 的 网 络 连 接 ， 
就 可 以 穿 透 NAT 的 防火 墙 。 为 了 提高 CMAN 的 效率 ，CMAN 连接 池 使 用 了 共享 服务 器 技术 , 这 
样 一 个 服务 进程 就 可 以 为 多 个 通过 CMAN 连接 的 客户 端 提供 会 话 服务 。 
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从 上 面 的 讨论 中 , 我 们 了 解 了 会 话 及 其 容器 服务 进程 之 间 的 关系 。 会 话 是 依赖 于 其 服务 进程 
的 , 一 旦 服务 进程 出 现 故 障 ， 会 话 也 将 会 出 现 故 障 。 因 此 ， 如 果 想 要 终止 某 个 会 话 正 在 进行 的 操 
作 ， 有 两 种 办 法 ， 一 是 杀 死 该 会 话 ， 我 们 可 以 通过 ALTER SESSION KILL 命令 杀 死 这 个 会 话 ; 
此 外 ， 也 可 以 直接 杀 死 会 话 对 应 的 服务 进程 。 


理解 DB Cache 


DB Cache 是 Oracle 数据 库 中 对 性 能 影响 最 大 的 组 件 ， 优 化 DB Cache 也 是 一 个 ОВА 最 基本 
的 职责 。 搞 过 软件 开发 的 人 都 知道 ， 缓 冲 区 是 提高 性 能 的 有 效 机 制 ，DB Cache 的 存在 主要 是 为 
了 提高 会 话 访问 数据 文件 中 数据 的 效率 。 

Oracle 的 DB Cache 机 制 与 其 数据 存储 结构 关系 十 分 紧密 ,Oracle 的 数据 在 文件 中 是 以 Block 
为 单位 存放 的 ， 因 此 DB Cache 和 数据 块 紧密 对 应 。 在 内 存 中 ，DB Cache 存储 的 就 是 Block 的 完 
整 镜像 。 

对 于 一 般 的 DBA 而 言 , 其 实 并 不 需要 十 分 深入 地 了 解 DB Cache 的 内 部 算法 , 只 要 了 解 一 些 
最 为 粗浅 的 原理 性 规则 , 就 可 以 解决 日 常 遇 到 的 超过 90% 的 相关 问题 了 , 只 有 少量 的 问题 会 涉及 
DB Cache 的 算法 。 因 此 ， 老 白 在 本 节 的 开始 只 介绍 一 些 普通 DBA 需要 了 解 的 DB Cache 的 基础 
概念 ， 随 后 的 小 节 中 介绍 的 关于 DB Cache 的 内 部 原理 是 专门 写 给 希望 深入 了 解 DB Cache 的 读 
者 的 ， 这些 较为 星 深 的 文字 ,你 完全 可 以 先 跳 过 ,等 到 直到 问题 时 再 来 做 深入 的 研究 。 通 过 下 面 
介绍 的 内 容 ， 读 者 能 够 了 解 到 DB Cache 一 些 最 为 关键 的 概念 ， 在 一 般 的 性 能 优化 中 ， 这 些 概念 
就 能 够 帮助 你 分 析 问 题 了 。 
对 于 一 般 的 DBA 来 说 ,需要 了 解 下 面 几 个 关于 DB Cache 的 概念 。 
о DB Cache 是 以 Block 为 单位 组 织 的 缓冲 区 , 不同 的 Block Size 的 数据 块 对 应 于 不 同 的 DB 
Cache, A Oracle 9i 开始 , RDBMS 支持 多 种 不 同 块 大 小 的 表 空间 ， 如 果 我 们 要 使 用 它们 ， 
就 必须 为 这 种 特殊 的 数据 块 大 小 的 数据 文件 设置 单独 的 缓冲 池 , 而 默认 的 DB Cache .Keep 
Pool. Recycle Pool 只 能 用 于 默认 块 大 小 的 表 空 间 。 

a 用 户 访 问 DB Cache 的 数据 比 访问 磁盘 上 的 数据 ， 速 度 要 快 数 十 倍 甚至 上 百倍 ， 因 此 应 用 
系统 应 该 尽 可 能 多 地 从 DB Cache 中 访问 数据 ,在 大 多 数 情况 下 ,DB Cache 的 命中 率 越 高 ， 
访问 性 能 就 越 好 。 
数据 库 刚 刚 启动 时 ，DB Cache 中 几乎 没有 用 户 数据 的 缓冲 ( 除非 在 系统 级 触发 右 中 做 了 
事先 加 载 )， 当 会 话 访问 数据 库 的 表 和 索引 时 ， 首 先 会 检查 DB Cache 中 是 否 存 在 该 数据 ， 
如 果 不 存在 ， 就 会 从 数据 文件 中 读 取 该 数据 块 到 DB Cache， 然 后 再 从 DB Cache 中 读 取 
该 数据 。 
定位 DB Cache 中 的 数据 块 是 通过 散 列 算法 实现 的 ， 对 于 DB Cache 来 说 ，Oralce 为 了 提 
高 数据 块 定 位 的 速度 ， 为 其 设计 了 一 个 Hash 链 结 构 ， 将 整个 DB Cache 中 正在 使 用 的 数 


口 
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据 块 都 放置 到 Hash 链 上 ， 这 个 Hash 链 是 由 多 个 Bucket 组 成 的 多 链 结构 ， 每 个 Bucket 就 
是 一 条 链 的 链 头 ， 从 链 头 引出 一 条 独立 的 双向 链 。Oracle 还 设计 了 一 个 算法 , 通过 数据 文 
件 的 文件 号 和 数据 块 的 块 号 ， 进 行 一 个 散 列 运算 ， 得 到 的 散 列 值 就 是 这 个 数据 块 所 在 的 
Bucket 的 号 码 。 如 果 要 查找 某 个 数据 块 ， 通 过 散 列 算法 ， 算 出 这 个 数据 块 所 在 链 的 链 头 
Bucket 的 位 置 ， 就 可 以 很 快 地 找到 链 头 ， 从 链 头 的 双向 链表 结构 扫描 下 去 ， 即 可 找到 相 
关 的 数据 块 。Bucket 的 数量 是 固定 的 ， 一旦 数据 库 启动 后 就 不 会 改变 ，Bucket 的 数量 由 
参数 _DB_BLOCK_HASH_BUCKETS 确定 ，8i 的 默认 值 是 2 x DB_BLOCK_BUFFERS, 
也 就 是 Buffer 数量 的 两 倍 , 9i 的 默认 值 是 大 于 两 倍 DB Block Buffer 数量 的 最 小 素数 ，10g 
的 默认 值 是 大 于 两 倍 DB Block Buffer 数量 的 最 小 的 2 的 帘 次 的 数值 。 虽 然 Oracle 的 每 个 
版 本 对 该 参数 的 定义 略 有 不 同 ， 但 是 有 一 点 是 不 变 的 ， 就 是 数据 库 缓冲 区 的 Hash Chains 
的 Bucket 的 数量 始终 大 于 DB Buffer 数量 的 两 倍 。 虽 然 我 们 无 法 获得 Oracle 内 部 散 列 算 
法 的 详细 细节 ,但 是 有 一 点 是 肯定 的 ，Oracle 设计 Hash 链 的 基本 思路 是 ， 每 个 链 上 有 最 
少 的 Buffer 数量， 最 佳 的 情况 是 每 条 链 上 只 有 一 个 Buffer。 

口 普通 会 话 只 读 取 和 修改 DB Cache, 不 负责 将 脏 数 据 写 人 磁盘 , 该 操作 一 般 是 由 DBWR 后 

台 进 程 来 完成 的 。 

口 如 果 某 个 会 话 要 访问 的 数据 当前 已 经 被 更 改 了 ， 而 这 个 会 话 需要 访问 该 数据 的 前 映像 
( Pre-Image ), 那 么 可 以 通过 UNDO 中 保存 的 数据 ,结合 当前 的 数据 块 ,生成 一 个 Pre-Image 
的 数据 块 缓冲 ， 这 个 数据 块 缓冲 是 针对 同一 个 数据 块 的 不 同 版 本 ， 因 此 它 将 和 当前 的 数 
据 块 存 放 在 相同 的 Bucket 上 ， 也 就 是 同一 条 Hash 链 上 。 也 就 是 说 ,在 DB Cache, fj 
一 个 数据 块 可 能 存在 多 个 版 本 ， 这 些 版 本 都 存储 在 同一 条 Hash 链 上 。 

о 访问 Hash 链 时 ， 为 了 保证 数据 访问 的 一 致 性 ， 通 过 cache buffers chains 门 锁 来 保护 Hash 
链 的 数据 结构 。 因 此 如 果 出 现 cache buffers chains 门 锁 争 用 ， 那 么 一 般 来 说 都 和 Hash 链 
的 访问 有 关 。 如 果 磁 到 该 门 锁 等 待 十 分 严重 ， 首 先 应 该 检查 是 否 存在 逻辑 读 (buffer get ) 
十 分 高 的 SQL， 看 看 这 些 SQL 的 执行 计划 是 否 存在 问题 ， 是 否 对 大 表 做 了 全 表 扫 描 。 此 
外 ， 较 严重 的 热 块 冲突 也 会 加 大 cache buffers chains 门 锁 的 争 用 ， 这 一 点 也 需要 注意 。 

口 除了 Hash 链 外 ，DB Cache 另外 一 个 十 分 重要 的 链 是 LRU 链 ， 如 果 某 个 会 话 需 要 分 配 一 
个 数据 块 缓冲 区 用 于 存放 一 个 新 的 数据 时 ， 就 会 从 LRU 链 上 查找 。 实 际 上 ， LRU 链 是 多 
条 链 的 总 称 ， 包 含 LRU, LRU-W 和 LRU-AUX 等 链 ， 不 过 对 于 大 多 数 DBA 来 说 ， 不 需 
要 很 深入 地 了 解 LRU 的 内 部 原理 ， 只 要 知道 LRU 链 是 一 种 以 类 似 LRU 算法 组 织 的 链 ， 
最 近 不 被 使 用 的 缓冲 区 会 被 最 先 重 用 即 可 。 确 实 ， 早 期 的 DB Cache 在 LRU 上 是 会 移动 
的 , 常用 的 缓冲 会 被 换 到 LRU 的 热 端 , 不 常用 的 缓冲 会 被 挤 到 LRU 的 冷 端 , 一 般 来 说 会 
话 分 配 Cache 时 ,会 从 LRU 的 冷 端 开始 查找 。 在 冷 端 找 到 脏 块 就 把 脏 块 移 到 LRU-W 
(DBWR 的 任务 就 是 将 LRU-W 中 的 脏 数 据 写 入 文件 ， 然 后 将 这 些 缓冲 区 从 LRU-W Б 
放 ， 变 为 可 用 缓冲 )， 找 到 没有 被 PIN 住 的 非 脏 块 ， 就 完成 了 缓冲 区 的 分 配 操作 。 

О 从 Oracle 8i 开始 , LRU 的 算法 有 所 改进 , LRU 链 上 的 缓冲 不 再 需要 移动 了 , 而 是 通过 tch 
计数 器 来 判断 某 个 数据 块 是 否 为 热 块 。 改 进 后 的 算法 ， 当 会 话 在 LRU 上 分 配 缓冲 时 ， 还 
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是 从 LRU 的 冷 端 开始 查找 ， 如 果 查 到 的 某 个 非 脏 的 缓冲 区 是 热 块 (根据 tch 值 的 高 低 判 
断 是 否 为 热 块 )， 就 会 跳 过 这 个 热 块 继续 往 下 查找 。 
O LRU 链 通过 cache buffers Iru chains 来 保护 ， 因 此 针对 LRU 链 的 操作 都 要 使 用 该 门 锁 。 如 
果 该 门 锁 发 生 较 为 严重 的 争 用 ， 说 明 数 据 块 缓冲 的 分 配 操作 出 现 了 性 能 瓶颈 ， 大 多 数 情 
况 下 ，DB Cache 容量 不 足 都 可 能 导致 该 门 锁 严 重 争 用 。 另 外 ， 如 果 数 据 库 缓冲 出 现 了 严 
重 的 抖动 ( 比如 ， 某 个 SQL 扫描 【了 一 张大 表 ， 几 个 G 的 数据 块 被 读 和 人 缓冲， 不 过 这 些 组 
冲 只 使 用 一 次 ， 很 快 就 会 被 其 他 数据 换 出 ， 如 果 经 常 出 现 类 似 的 情况 ， 数 据 库 缓冲 的 拌 
动 就 会 很 严重 )， 也 可 能 导致 该 门 锁 争 用 的 加 剧 。 
О Oracle 的 多 缓冲 技术 可 以 有 效 地 避免 数据 库 缓 冲 区 的 抖动 ， 除 了 默认 的 数据 块 缓冲 池 
(Default Pool) 外 ， 还 可 以 将 经 常 访问 的 数据 放 入 Keep Pool, 一 次 性 使 用 的 数据 可 以 使 
用 Recycle Pool, 设置 Recycle Pool 需 要 应 用 开发 配合 ， 因 此 目前 使 用 并 不 是 很 多 ，Keep 
Pool 的 使 用 确实 可 以 改善 LRU 算法 的 性 能 ,适合 几乎 所 有 系统 。 
RAC 环境 下 的 缓冲 区 融合 技术 是 一 把 双 刃 剑 ， 缓 冲 区 融合 技术 解决 了 多 个 实例 安全 访问 
同一 个 数据 库 的 问题 ， 同 时 也 大 大 提升 了 全 局 缓冲 的 访问 性 能 ， 但 是 如 果 全 局 缓冲 传输 
操作 的 数量 过 大 ， 很 容易 导致 性 能 问题 。 因 此 在 RAC 环境 下 ， 更 需要 减少 热 块 冲突 ， 减 
少 不 必 要 的 节点 间 DB Cache 的 传输 。 在 КАС 环境 中 ， 要 提高 全 局 缓冲 的 性 能 ， 除 了 在 
硬件 上 提高 私有 网 络 的 带宽 外 ， 尽 可 能 提高 DB Cache 的 命中 率 也 十 分 关键 ，DB Cache 
命中 率 高 了 ， 可 以 减少 大 量 由 于 Cache 未 命中 而 导致 的 实例 间 消 息 的 数量 ， 使 LMS 进程 
有 更 多 的 时 间 处 理 真正 的 Global Cache。 实 际 上 RAC 环境 的 缓冲 区 融合 (Cache Fusion ) 
技术 是 一 种 十 分 优秀 的 群集 技术 ， 通 过 高 速 的 私有 网 络 实现 全 局 资源 的 共享 ， 其 共享 效 
率 比 磁盘 共享 要 快 十 倍 以 上 。 一 个 典型 的 磁盘 单 块 读 的 响应 时 间 约 为 4 毫秒 ， 如 果 要 通 
过 磁盘 共享 数据 ， 一 个 操作 包含 了 多 个 文件 IO 操作 ( 写 、 读 ), 而 通过 缓冲 区 融合 算法 ， 
只 需要 将 Cache 从 一 个 节点 传输 到 另外 一 个 节点 就 行 了 , Cache 在 高 速 的 千 兆 网 络 上 传输 
的 时 间 一 般 来 说 小 于 1 毫秒 。 
DB Cache 的 算法 十 分 复杂 ,我 们 没有 必要 去 完全 了 解 ， 只 需要 了 解 DB Cache 的 大 体 结构 和 
总 体 算法 。 了 解 这 些 算法 的 目的 是 为 了 更 好 地 理解 相关 的 门 锁 和 等 待 事件 , 以 便于 分 析 和 处 理 相 
关 的 性 能 问题 。 如 果 我 们 一 味 地 去 强调 精确 的 算法 ,那么 就 本 末 倒 置 了 。 FEAST, SE DRE Ae 
人 和信 深 地 介绍 DB Cache， 让 大 家 掌握 DB Cache 性 能 分 析 和 优化 的 基本 技术 。 
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DB Cache 是 十 分 复杂 的 , 很 多 DBA 都 想 了 解 DB Cache 到 底 是 怎么 构成 的 。 事 实 上 从 Oracle 
发 展 了 那么 多 年 来 看 ，DB Cache 的 变化 是 很 大 的 ，Oracle 的 每 个 大 版 本 都 会 对 DB Cache 的 相关 
算法 做 相当 大 的 调整 , 从 而 大 幅 提升 数据 库 的 性 能 。 不 过 虽然 DB Cache 的 管理 算法 一 直 在 变化 ， 
但 其 基本 原理 并 没有 发 生 太 大 的 变化 。 在 本 节 中 ， 我们 就 简单 探讨 一 下 DB Cache 的 一 些 基本 结 
构 和 原理 ， 但 本 文 并 不 是 DB Cache 的 完整 描述 ， 只 是 通过 一 些 知识 点 ， 让 DBA 了解 DB Cache 
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的 基本 面貌 和 算法 。 


ТЖ, DB Cache 是 由 一 系列 共享 内 存 组 成 的 , 是 在 SGA 中 统一 分 配 的 一 个 组 件 。SGA 管理 
的 共享 内 存 区 域 是 通过 类 似 shmget,shmat 等 UNIX 系统 调用 获取 的 。 根据 操作 系统 及 其 参数 设置 
的 不 同 ，SGA 可 能 是 经 过 多 个 共享 内 存 申请 获取 到 的 内 存 的 总 和 。 在 SGA 中 ， 系 统 根据 初始 化 
参数 的 设置 ， 分 配 相应 的 DB Cache。 

众所周知 ，SGA 是 以 GRANULE 为 单位 的 ， 大 多 数 系统 的 GRANULE 的 大 小 一 般 为 16M, 
SGA 比较 小 的 系统 可 能 为 4M。 每 个 GRANULE 中 包含 多 个 Buffer, 这 些 Buffer 的 大 小 和 数据 块 


的 大 小 相同 。 大 家 要 注意 的 是 , 在 DB Cache P, MEET Buffer， 还 有 一 种 被 称 为 Buffer 


HeadGBHB) 的 控制 结构 ,这 种 控 


出 结构 在 Oracle 的 内 部 被 命名 为 kcbbh。 各 个 版 本 的 Oracle 数据 库 


的 kcbbh 结构 都 有 所 不 同 ， 以 Oracle 9; 为 例 ，kcbbh 是 一 个 188 字 节 的 控制 结构 ， 我 们 可 以 通过 
伪 代 码 来 看 看 它 的 详细 结构 ， 老 白 将 通过 下 列 伪 代 码 结构 来 说 明 DB Cache Buffer Head 的 结构 ， 


如 代码 清单 2-1 所 示 。 


代码 清单 2-1 
struct kcbbh ( 

void * 
i nt 
krdba 
ub4 
b1 
b1 
word 
kf i 
kobj d 
kobjn 
ptr t 
kscn 
kggl k 
kggl k 
b1 
b1 
kggl k 
b1 
b1 
ub2 
ub4 
kcrda 
kcrda 
kcbcr 
kssob * 
kcrfkd 
ub2 
ub2 
ub2 
kggl k 
kggl k 
struct kcbwds * 


HASH 链 的 指针 
Азн; 
DBA +; 


flag; /* 修改 时 需要 Cache buffers chains HA */ 


buffer 状态 ; 

buffer 持 有 状态 ; /* NULL, SHR, EXCL */ 
SCA class; 

绝对 文件 号 ; 

对 象 的 data object ID ; 

对 象 的 0bj ect id; 

buffer 的 地 址 指针 

事务 DSCN; 

buffer 使 用 队列 指针 ; 

buffer 等 待 队列 指针 ; 

一 个 独立 的 修改 调用 产生 的 修改 的 数量 ; 
如 果 修 改 失败 需要 恢复 的 状态 位 ; 

LRU 链 指针 ; 


是 否 在 LRU-W 链 上 Kcbbhfoq; /* TRUE 表示 在 1ru-W E*/ 


LRU 门 锁 保 护 标 识 ; 

tch 计数 器 ; 

最 近 一 次 tch 增长 的 时 间 ; 
磁盘 恢复 需要 的 最 低 T ba; 
缓冲 区 恢复 需要 的 最 低 Tbal 
一 致 性 度 相 关 数 据 ; 


恢复 相关 STATE OBJECT 的 指针 1* 恢复 时 需要 的 结构 


数据 块 中 变化 的 最 大 SCN; 
FERRET Ж 

kcbbhssid; 

WORKING SET 中 的 ckpt queue $55 Z5; 
ckpt queue 的 指针 ; 

文件 Ckpt queue 指针 ; 

WORKING SET 的 指针 ; 


struct kcbbh. ОМК Ich kcbbhsh UNK Ich kcbbhsh 


*| 
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从 上 面 的 伪 代 码 中 ， 我 们 可 以 看 到 在 DB Cache 中 有 一 些 很 重要 的 链 ， 这 些 链 上 串联 的 每 个 
节点 都 是 Buffer Header, 而 不 是 直接 的 Buffer, Н Buffer Header 指向 真正 的 Buffer.Oracle 的 Buffer 
是 由 大 小 相同 的 数据 块 组 成 的 。 同一 个 BUFFER 的 所 有 数据 块 的 大 小 都 相同 。 Default Pool, Keep 
Pool, Recycle Pool 的 大 小 和 DB BLOCK SIZE 相同 。nk Pool 的 Buffer 的 块 大 小 和 


DB_BLOCK_SIZE 不 同 ， 如 图 2-1 所 示 。 
Buffer 
Headers 


Buffers 


[Granule ^ — 


2-1 


一 个 Buffer 的 Buffer Head 处 于 同一 个 GRANULE 中 ,在 每 个 GRANULE 的 头 部 都 是 Buffer 
Head, Buffer Head 的 kcbbhba 指针 指向 Buffer 的 地 址 。 

对 于 不 同 大 小 的 Block 和 GRANULE， 每 个 GRANULE 中 可 以 存放 的 Buffer 数量 不 同 ， 表 
2-1 是 Julian Dyke 在 其 SG4 Internals 讲义 中 提供 的 参考 数据 。 


表 2-1 
数据 块 大 小 ( 字 节 ) 每 个 Granule 的 BUFFER 数量 

4mb 16mb 
2048 1875 7503 
4096 979 3916 
8192 500 2002 
16384 253 1012 
32768 127 509 


在 Oracle 9i 数据 库 中 ， 如 果 我 们 的 Block 大 小 是 8K, mi GRANULE 的 大 小 为 16M， 那 么 
每 个 GRANULE 可 以 包含 2002 个 Buffer, 这 和 16M 除 以 8380 ( EH 8192+188 ) 得 到 的 结果 是 一 
致 的 。 

DB Cache 中 有 多 种 类 型 的 链 ， 这 些 链 大 多 数 是 双向 链表 ， 这 些 链 表 可 以 归结 为 两 类 ，LRU 
БЕЛП HASH 链 。LRU 链 根 据 LRU 算法 对 DB Cache 进行 Buffer 分 配 和 换 出 (Age Out) 的 管理 
(从 Oracle 8 开始, LRU 算法 有 所 变化 , 在 后 面 会 详细 描述 ), 而 HASH 链 能 够 加 快 对 DB Cache 
的 访问 〈 大 家 要 注意 ， 这 两 种 链表 的 作用 是 不 同 的 ， 一 个 是 为 了 分 配 和 换 出 ， 另 一 个 则 是 为 了 
WARS )。 
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DB Cache 的 算法 从 2 开始, 有 了 很 大 的 变化 , 因此 我 们 要 密切 关注 这 些 变 化 ,在 Si B, LRU 
链 中 的 Buffer Head 是 要 根据 “ 热 ” 的 程度 在 LRU 链 上 移动 的 ， 一 旦 某 个 Buffer 从 “ 冷 块 ” 变 
为 “ 热 块 "， 那 么 这 个 Buffer 就 需要 移 到 LRU 链 的 热 端 ， 这 样 的 算法 虽然 可 以 保证 “ 热 块 ” 尽 
可 能 长 时 间 地 保存 在 DB Cache 中 不 被 换 出 , 但 是 会 增加 LRU 链 的 维护 成 本 和 相关 门 锁 的 争 用 ， 
从 而 降低 LRU 链 的 性 能 。 从 Oracle 8i 开始， 为 了 解决 热 块 在 LRU 链 上 不 停 移 动 带 来 的 性 能 问 
题 ， BUFFER HEAD 的 数据 结构 中 引入 了 一 个 新 的 计数 器 TCH ( 访问 计数 器 )， 这 个 计数 需 用 
于 记录 某 个 Buffer 被 访问 的 次 数 。 由 于 ТСН 的 引入 ，Buffer Header 不 需要 再 在 LRU 链 上 移动 
T, `4 TCH 达到 某 个 国 值 ( 通过 参数 db aging hot criteria 确定 )， 那 么 这 个 块 就 被 设置 Buffer 
热 块 标 识 。 当 我 们 需要 分 配 一 个 Buffer 的 时 候 , 会 话 总 是 从 LRU 链 的 冷 端 ( 也 叫 尾 端 ) 开始 向 
前 搜索 ， 在 这 种 算法 中 ， 一 个 热 块 可 能 被 挂 在 LRU 链 的 尾 端 ， 但 是 因为 我 们 引入 了 TCH 和 热 
块 标识 ， 因 此 当 会 话 找到 了 一 个 可 以 使 用 的 设置 了 热 块 标识 的 Buffer 时 ， 就 会 自动 跳 过 这 个 
Buffer， 继 续 往 下 搜索 ， 而 不 会 直接 使 用 这 个 Buffer， 这 样 也 就 确保 了 访问 比较 频繁 的 数据 块 不 
会 被 很 快 换 出 。 

新 的 算法 也 从 另外 的 角度 确保 了 “最 近 使 用 ， 最 后 换 出 ”的 原则 。 当 一 个 新 的 数据 块 被 载 人 
Buffer 时 ， 系 统 会 从 LRU 链 上 找到 一 个 Buffer ( 其 实 是 找到 Buffer Header )， 然 后 摘 下 该 Buffer, 
写 和 人 数据 , 这 时 需要 把 这 个 Buffer RIEA LRU 链 , 这 个 挂 入 点 是 由 参数 db. percent. hot. default 
确定 的 ， 其 含义 是 LRU 链 热 端 尾部 的 位 置 ， 这 个 参数 是 百分比 ， 默 认 值 为 50%。 也 就 是 说 ， 新 
的 Buffer feet: A LRU 链 的 中 部 ， 而 老 的 Buffer 将 被 一 直 往 尾 部 挤 。 一 般 来 说 ， 这 个 参数 的 默 
认 值 对 于 绝 大 部 分 系统 是 不 需要 调整 的 , 我 们 也 可 以 通过 调整 这 个 参数 , 使 新 Buffer 搬入 的 位 置 
更 靠近 热 端 或 者 冷 端 。 调 整 这 个 参数 对 LRU 算法 的 影响 很 大 ， 因 此 要 特别 谨慎 ， 对 于 99% 甚 至 
99.99% 的 系统 来 说 ，Oracle 的 默认 配置 是 足够 好 的 ， 哪 怕 不 是 足够 好 ， 绝 大 多 数 DBA 也 无 法 计 
算出 真正 适合 你 的 系统 的 最 佳 值 。 盲目 调整 这 个 参数 可 能 导致 十 分 严重 的 后 果 , 请 大 家 不 要 轻易 
在 生产 系统 上 进行 尝试 。 

我 们 总 在 讨论 LRU 链 ， 而 实际 上 LRU 链 是 一 组 链 的 总 称 ， 而 不 是 一 条 链 ,在 Oracle 的 各 个 
ARASH, LRU 链 的 数量 是 不 一 样 的 。 从 8i 或 者 以 后 的 版 本 来 看 ， 有 以 下 几 条 重要 的 LRU 链 : 

O LRU LIST (也 叫 replacement list )， 前 台 进 程 从 该 链 中 查找 可 重用 的 Buffer， 这 条 链 从 8i 
开始 不 再 采用 LRU 算法 进行 管理 了 , 而 采用 了 一 种 我 们 上 面 提 到 的 改良 的 LRU 算 法 , 其 
核心 部 分 就 是 TCH。 当 一 个 新 的 Buffer 加 入 这 条 链 时 ， 是 加 入 到 热 端的 尾部 ， 热 端 尾部 
的 位 置 由 _db_percent_hot_default ,_db_percent_hot_keep fil db percenX hot recycle 这 些 参 
数 确 定 , 它们 分 别 作 用 于 Default Pool. Keep Pool 和 Recycle Pool, _db_percent_hot_default 
参数 的 默认 值 是 50% ,也 就 是 链 的 中 间 ，_db_percent_hot keep fll db. percent. hot. recycle 
是 0%。 查 找 可 重用 Buffer 时 ， 从 LRU 的 冷 端 开始 ， 如 果 发 现 某 个 Buffer 是 热 块 ， 就 会 
Wt s 

O LRU-W LIST (write list )， 也 就 是 我 们 常 说 的 脏 数 据 链 (Dirty List) LRU-W 存放 的 都 是 
脏 块 , 也 就 是 需要 存盘 的 数据 块 , DBWR 通过 LRU-W 生成 写 批量 , 完成 数据 块 刷 入 硬盘 
的 操作 。 
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口 LRU-AUX LIST Æ LRU LIST 中 的 一 条 子 链 ， 它 的 存在 是 为 了 提高 LRU 算法 的 性 能 。 当 
LRU-W 上 的 脏 数据 被 写 盘 后 , 这 些 Buffer 就 可 以 重用 了 。 但 它们 并 没有 被 马上 放 入 LRU 
链 ， 而 是 被 放 和 人 LRU-AUX 链 。 前 台 进 程 查找 空闲 Buffer 时 ， 首 先 从 AUX 链 开始 查找 ， 
只 有 在 AUX 链 中 找 不 到 可 用 的 Buffer 时 ， 才 去 搜索 LRU f£; 

口 LRU-PLIST 这 条 链 上 的 对 象 ,一 般 在 被 写 人 时 都 存在 一 定 的 锁 或 者 被 某 个 会 话 PIN FET, 
此 这 些 Buffer 往往 被 写 入 后 还 不 能 马上 使 用 ,需要 释放 锁 或 者 降低 锁 的 级 别 。 这 条 链 
上 的 Buffer 在 尾部 加 入 ,DBWR 从 头 部 开始 写 ,一旦 某 个 Buffer 人 处 于 可 释放 的 状态 ,DBWR 
会 将 其 移 到 LRU-AUX. 

口 LRU-XO LIST (reuse object list )， 当 某 个 对 象 被 刷新 (DROP、TRUNCATE 等 ) Hf, CKPT 

进程 将 这 个 对 象 的 所 有 Dirty 和 Current 的 Buffer jit A LRU-XO LIST. 

CQ LRU-XR LIST (reuse range list )， 类 似 于 LRU-XO LIST. 

全 表 扫 描 会 对 DB Cache 造 成 较 大 的 影响 ,因为 有 大 量 的 数据 块 需要 被 扫描 ,并 放 人 DB Cache 

中 。 为 了 尽 可 能 少 地 影响 DB Cache， 对 于 大 表 的 全 表 扫 描 ，Oracle 数据 库 设计 了 一 个 算法 ,使 

这 类 扫描 操作 增加 的 Buffer 被 放 在 LRU 链 的 尾部 , 而 不 是 中 部 , 因此 这 些 Buffer 会 被 最 快 换 出 ， 

尽 可 能 不 影响 LRU 链 中 的 热 块 ， 不 会 将 较 常 用 的 数据 很 快 挤 到 尾部 。 而 小 表 的 全 表 扫 描 是 和 大 

表 全 表 扫 描 不 同 的 ， 小 表 全 表 扫 描 对 DB Cache 的 影响 较 小 ， 因 此 可 以 对 这 些 Buffer 采用 和 普通 

Buffer 一 样 的 操作 ， 而 不 是 将 它们 放 到 LRU 链 的 尾部 。 

前 面 讨论 了 关于 LRU 链 的 相关 概念 和 基本 算法 ,大 家 也 了 解 到 了 LRU 链 主要 用 来 分 配 Buffer 

和 管理 Buffer 的 换 出 。 实 际 上 ， 对 于 DB Cache， 还 有 一 个 问题 需要 关注 ， 就 是 如 何 对 Buffer Ht 

行 寻 址 。 在 一 个 很 大 的 数据 库 绥 冲 区 中 ,我 们 如 何 通过 最 小 的 代价 找到 相关 的 Buffer， 这 一 点 十 

分 关键 。 因 为 在 Oracle 数据 库 中 ， 如 果 我 们 要 查找 某 个 数据 ， 首 先 需 要 到 DB Cache 中 去 查找 ; 

如 果 在 DB Cache 中 找 不 到 ， 我 们 才 会 从 物理 文件 中 读 取 。 在 一 个 并 发 量 很 大 的 系统 中 ， 这 种 寻 

址 的 效率 决定 了 系统 的 性 能 。 当 我 们 要 访问 某 个 数据 块 的 时 候 , 能 够 依赖 的 参数 就 是 文件 号 和 块 

号 。 它 们 决定 了 某 个 特定 的 数据 块 ， 因 此 我 们 可 以 使 用 文件 号 和 块 号 作为 寻 址 的 参数 。Oracle 数 

HERI HASH 链 就 是 基于 这 个 思路 设计 的 。Oracle 在 共享 池 中 设计 了 一 个 物理 结构 ,就 是 HASH 

链 结构 ，DB Cache 的 HASH 链 由 多 条 子 HASH 链 组 成 ， 每 条 子 链 我 们 称 之 为 一 个 Bucket。 每 条 

HASH 链 都 是 一 条 双向 的 链表 ， 链 表 的 每 个 节点 对 应 一 个 Buffer Header。 默 认 情 况 下 , 在 HASH 

链 结 构 中 ，Bucket 的 数量 大 于 Buffer 数量 的 两 倍 , 一 个 数据 块 的 文件 号 和 块 号 通过 散 列 算法 , 会 

定位 到 唯一 的 一 个 Bucket E, 因此 该 数据 块 在 DB Cache 中 的 Bucket 的 位 置 是 固定 的 。 通过 这 种 

机 制 ，Oracle 就 可 以 在 DB Cache 中 快速 定位 到 这 个 数据 块 了 。 由 于 采用 的 是 散 列 算法 ， 因 此 不 

同 的 数据 块 可 能 得 到 相同 的 散 列 值 ， 也 就 是 说 它们 存放 的 Bucket 可 能 是 相同 的 ,那么 这 些 

BUFFER 就 被 串 在 同样 的 HASH 链 上 。 不 过 这 种 情况 出 现 的 机 会 不 大 ， 一 条 HASH 链 上 的 节点 

数量 一 般 都 很 少 ， 因 此 查找 某 个 数据 块 的 BUFFER 的 操作 一 般 都 是 很 快 的 。 

散 列 算法 使 用 的 参数 是 文件 号 和 块 号 ， 因 此 一 个 数据 块 的 不 同 版 本 ,在 DB Cache 的 HASH 

链 中 肯定 在 同一 条 链 上 ， 因 为 它们 具有 相同 的 文件 号 和 块 号 。 之 前 我 们 也 了 解 过 , 一 个 数据 块 的 

一 致 性 读 块 (CR Block ) 是 由 当前 状态 的 数据 块 和 UNDO 中 的 相关 数据 合并 后 生成 的 ， 能 够 反 
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映 之 前 某 个 时 间 点 的 数据 情况 。 在 一 个 变化 十 分 频繁 ,大 查询 ( 持续 时 间 较 长 的 查询 ) 较 多 的 系 
统 中 ， 某 个 数据 块 的 CR Block 的 数量 可 能 会 很 多 ， 这 样 就 会 增加 查找 该 数据 块 的 CR Block 的 操 
作 开 销 ， 在 操作 过 程 中 持 有 门 锁 的 时 间 也 会 变 长 。 

综合 我 们 前 面 讨论 的 LRU EFI HASH #6, 我 们 用 图 2-2 来 描述 DB Cache， 这 只 是 一 张 示意 
图 ,真正 的 结构 要 复杂 得 多 , 这 里 忽略 了 很 多 DB Cache 的 细节 ,不 过 从 图 中 可 以 了 解 到 DB Cache 
的 概貌 。 


LRU chain: 双向 链表 
i | 


int "eim 
LRUW chain; H DBWR 5 A. 


LI] 


hash bucket 1 BH 40 BH2 BH N 


hash bucket 2 | 


DB cache 


图 22 


如 果 要 真正 了 解 DB Cache 的 结构 , 首先 需要 了 解 一 下 Working Set 的 概念 。 数 据 结构 kcbwds 
是 Kernal Cache Buffer Working Set management Descriptors 的 简称 , 在 数据 库 中 XSKCBWDS 视图 
就 是 内 存 结构 kcbwds 的 关系 型 描述 。 我 们 可 以 通过 伪 代 码 看 一 下 10.2 版 本 数据 库 的 kcbwds， 如 
代码 清单 2-2 所 示 。 


代码 清单 2-2 
Struct kcbwds í 
kcbkcql ckpt q HA 2]; /* 2 AF9 */ 
kcbsds WS 虚拟 扩展 ， 
ub4 WS 的 状态 ; 
kcbwlid WS 10; /* 对 应 bh 中 的 WORKI NG SET ID */ 
word 包含 这 个 WS 的 BUFFER POOL; 
word WS 的 块 大 小 索引 号 ; 
dbl kz WS 的 块 大 小 ; 
word WS 的 NUMA 处 理 器 租 ; 
word WS 使 用 的 DBWR >; 


kcbwl WS Ht; 
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kcbwbl WS 列表 ; |* 包含 LRU 和 LRU- AUX 链 的 指针 等 信息 # | 
kgglk * LRU & bag As S4 BH 的 地 址 ; 

uwor d LRU & E 3x89 8 2 rt; 

uword LRU & E AA353x 2 49 BUFFER жж; 

uword LRU & EB ip dA as a BUFFER 数量 ; 

uword 当前 WS 中 的 BUFFER 数量 ; 

kcbohtab * object queue 的 HASH 表 的 指针 ; 

uword 前 台 会 话 从 Wo PRA buffer 的 计数 器 ; 

Word "buffer 中 请 的 计数 器 ; 

uword dbwr 从 这 个 WS 写 的 buffer 的 计数 器 ; 

uword dbwr 在 WS 中 扫描 的 buffer 的 计数 器 ; 

uword 在 WS 中 产生 free buffer waits 的 计数 器 ; 

uword A WS 中 产生 的 Write complete 等 待 的 计数 器 ; 
uword 在 WS 中 产生 的 BUFFER BUSY WAITS 的 计数 器 ; 

uwor d A£ WS 中 产生 的 Free Buffers Inspected 的 计数 器 ; 
uwor d EW 中 产生 的 Dirty Buffers Inspected 的 计数 器 ; 
uword 在 WS 中 产生 的 Pinned Buffers Inspected 的 计数 器 ; 
uword 在 WS 中 产生 的 Hot buffers moved to head 的 计数 器 
uword 在 WS 中 产生 的 DB Block Changes 的 计数 器 ; 

uword EWS 中 产生 的 DB Block gets 的 计数 器 ; 

uwor d 在 WS 中 产生 的 Consistent gets 的 计数 器 ; 

uwor d EWS 中 产生 的 物理 读 的 计数 器 ; 

uwor d & WS 中 产生 的 物理 写 的 计数 器 ; 

uword WS 中 前 台 进 程 扫描 深度 

uword 脏 数 据 最 大 比例 (超过 该 比例 激发 DBWR 5) ; 

uword pwbcnt; 

uwor d protcnt; 


} 

如 果 你 认真 地 阅读 了 上 面 的 伪 代 码 ， 就 不 难 发 现 ，Working Set 实际 上 定义 了 一 个 DB Cache 
的 工作 组 。Oracle 为 了 提高 DB Cache 的 刷新 性 能 ， 将 整个 DB Cache 划分 为 多 个 Working Set. 
每 个 Working Set 管 理 一 部 分 DB Cache, 且 拥有 独立 的 LRU 链 结构 ( 包含 LRU LRU-W ,LRU-AUX 
等 )， 并 有 独立 的 门 锁 进 行 管理 。 

在 这 段 伪 代码 的 后 半 部 分 , 包含 了 这 个 Working Set 的 一 些 统计 信息 , 我 们 可 以 在 AWR 报告 
中 看 到 这 些 统计 信息 。 

不 同 的 Working Set， 是 由 独立 的 DBWR 进行 维护 的 ， 一 个 DBWR 进程 管理 一 个 或 者 多 个 
Working Set. TE CPU 环境 下 ,设置 多 个 DBWR， 用 于 管理 多 个 Working Set， 这 样 可 以 提高 
DB Cache 脏 块 的 处 理 速度 。 如 果 我 们 碰 到 了 大 量 的 free buffer wait 等 待 或 者 write complete 等 待 ， 
那么 说 明 可 能 是 DB Cache 太 小 了 , 或 者 DBWR 写 人 速度 太 慢 了 ， 这 时 增加 DBWR 的 数量 也 许 
可 以 有 效 地 改善 这 方面 的 性 能 。 不 过 一 般 情况 下 ,将 DBWR 的 数量 设置 得 过 多 ( 比如 大 大 超过 
CPU 数量 ) 意义 并 不 大 ， 因 为 这 样 可 能 会 导致 CPU 资源 出 现 争 用 , 无 法 保证 所 有 的 DBWR 都 能 
够 有 足够 的 CPU 资源 进行 工作 。 这 时 可 能 有 些 朋 友 就 会 考虑 了 ， 是 不 是 DBWR 数量 大 于 CPU 
的 数量 就 没有 意义 了 呢 ? 实际 上 并 没有 那么 简单 ， 这 是 一 个 需要 综合 考虑 的 问题 ， 因 为 DBWR 
采用 的 是 批 处 理 写 的 模式 ， 组 织 写 作业 和 异步 写 这 些 操作 可 以 交叉 进行 。 如 果 系 统 的 CPU 资源 
还 未 磁 到 瓶 贷 ， 设置 DBWR 数量 超过 CPU 的 数量 也 可 能 提高 DBWR 的 总 体 性 能 。 不 过 一 般 情 
况 下 ， 如 果 脏 块 产生 过 快 ， 说 明 系 统 的 负载 很 高 ， 这 时 候 设 置 太 多 的 DBWR 帮助 不 大 。 
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2.2 DB Cache 的 分 配 和 DBWR 的 相关 算 ; 


在 DB Cache 的 算法 中 ,数据 库 启动 之 初 , 空闲 的 Cache 都 是 在 LRU 链 上 的 。 前 台 进 程 需要 
分 配 DB Cache 的 时 候 ， 从 LRU 链 的 冷 端 开始 扫描 ， 查 找 可 用 的 Cache。 找 到 Cache 后 ， 根 据 要 
读 入 的 数据 块 的 RDBA， 通 过 散 列 算法 找到 一 个 HASH 链 ， 将 这 个 数据 块头 上 的 HASH 链 相关 
指针 链接 到 HASH 链 上 。 

前 人 台 进 程 只 负责 将 数据 块 从 文件 中 读 取 到 DB Cache rB, Im DB Cache 中 的 脏 数 据 是 由 专门 
的 后 台 进程 来 负责 写 和 人 数据 文件 的 ， 这 个 后 台 进 程 就 是 DBWR。 在 介绍 详细 的 算法 之 前 ， 我 们 
首先 需要 学 习 几 个 数据 库 的 统计 数据 。 这 几 个 统计 数据 对 于 我 们 理解 DB Cache 的 算法 十 分 重要 。 
由 于 DB Cache 的 算法 改进 十 分 频繁 ， 因 此 本 节 介 绍 的 一 些 算法 ， 都 是 基于 & 版 本 的 ，%i 或 者 更 
高 的 版 本 中 ， 算 法 的 核心 并 未 改变 ， 只 是 在 细节 上 有 所 不 同 ， 请 大 家 阅读 本 节 时 注意 。 

首先 我 们 来 看 看 Foreground scan depth 这 个 参数 ， 它 和 前 台 进 程 搜索 DB Cache AX. AA 
进程 要 分 配 DB Cache 的 时 候 ， 会 从 LRU 的 尾部 开始 搜索 ， 如 果 发 现 了 可 用 的 DB Cache 就 PIN 
住 使 用 。 如 果 找 到 的 这 个 Cache 目前 是 脏 的 , 还 没 写 盘 或 者 被 其 他 会 话 РІМ Е, 或 者 被 标识 为 热 
Hk, 那么 这 个 Cache 就 不 能 使 用 ， 需 要 继续 向 前 搜索 。 而 这 种 搜索 工作 有 可 能 进行 很 长 时 间 都 无 
法 找到 可 用 的 Cache， 这 样 就 极 大 地 影响 了 LRU 链 的 性 能 ， 因 此 需要 定义 一 个 最 大 深度 ， 一 旦 
超过 这 个 搜索 深度 ， 就 放弃 搜索 ， 同 时 记录 一 个 标志 位 ， 通 知 DBWR 刷新 脏 数 据 到 磁盘 。 同 时 
前 台 进 程 进入 休眠 状态 ， 等 待 free buffer 的 消息 ， 收 到 该 消息 后 重新 开始 查找 工作 。 这 个 深度 默 
认 设 置 为 DB Cache 的 1/4， 并 可 以 通过 参数 _db_block_max_scan_pct 来 调整 (在 每 个 版 本 中 ， 该 
参数 的 初始 值 都 会 有 所 不 同 )。 

在 搜索 可 用 Cache 的 时 候 ， 如 果 发 现 某 个 BUFFER 是 脏 的， 那么 前 台 进 程 就 会 马上 将 该 
BUFFER 从 LRU 链 上 摘 下 ， 放 到 LRU-W 的 尾部 ， 并 且 增 加 buffers moved to the dirty queue by 
foregrounds 统计 量 。 如 果 发 现 LRU-W 链 的 长 度 已 经 大 于 Max dirty queue， 那 么 前 台 进 程 也 会 停 
止 搜索 操作 ， 并 记录 一 个 标志 位 ， 通 知 DBWR 将 脏 数据 写 到 磁盘 上 。 同 时 前 台 进 程 进 入 休眠 状 
态 ， 等 待 DBWR 完成 写 人 。 这 种 情况 下 ， 如 果 known clean buffers 计数 器 的 值 不 是 0， 那 么 就 会 
减少 known clean buffers 的 计数 。known clean buffers 是 一 个 计数 器 ， 该 计数 器 记录 的 是 当前 的 
DB Cache 中 可 能 的 干净 块 (也 就 是 非 脏 的 块 ) 的 数量 。 这 个 计数 器 在 DB Cache 相关 算法 中 还 有 
一 些 其 他 的 用 处 ， 等 老 白 慢 慢 介 绍 。Max dirty queue 的 大 小 是 Max write batch И, Мах write 
batch 是 一 次 写 批 处 理 操作 的 最 大 数量 ， 可 以 通过 参数 db block write batch 来 调整 。 

如 果 前 台 进 程 在 搜索 中 找到 了 可 用 的 BUFFER， 那 么 它 就 会 将 该 BUFFER 移动 到 LRU 链 热 
端的 尾部 ,同时 减少 known clean buffers 的 计数 .如果 known clean buffers 计数 小 于 dbwr scan depth 
的 一 半 ， 那 么 前 台 进 程 也 会 设置 标识 ， 触 发 DBWR 写 操作 。 一 般 情 况 下 ，dbwr scan depth 初始 
化 时 的 值 等 于 min scan depth ( 默认 为 DB Cache 的 1/4 )， 不 过 这 个 参数 会 在 数据 库 运 行 过 程 中 动 
态 调整 。 

上 面 所 说 的 算法 并 不 能 完全 反映 Oracle 的 真实 算法 ,不 过 大 体 上 能 够 体现 其 主要 思想 。 当 
DB Cache 中 可 用 的 空闲 块 不 足 的 时 候 ， 会 设置 DBWR Make Free Message， 该 消息 会 唤醒 休眠 的 
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DBWR 进程 ， 并 开始 工作 。 当 这 个 消息 被 DBWR 收 到 后 会 发 生 什么 呢 ? 

DBWR 首先 会 获取 LRU 门 锁 ， 清除 DBWR Make Free Message 标志 ， 然 后 会 检查 LRU-W 
链 。 如 果 LRU-W 是 空 的 ， 并 有 日 known free buffers 计数 大 于 dbwr scan depth 的 一 半 ， 那么 DBWR 
什么 都 不 做 ， 直 接 释 放 门 锁 ， 然后 继续 “睡觉 ”。 

如 果 DBWR 发 现 LRU-W 上 的 BUFFER 数量 不 够 一 次 DBWR BATCH 操作 , 那么 DBWR 就 
会 从 LRU 的 尾部 开始 搜索 脏 数 据 块 ， 发 现 后 ， 将 这 个 数据 块 移动 到 LRU-W 的 尾部 。 如 果 扫 描 
的 数据 块 没 有 被 移动 到 LRU-W, 那么 clean buffers scanned 计数 器 会 增加 。 搜 索 结束 的 条 件 是 
LRU-W 上 的 数据 块 数量 达到 了 dbwr batch 的 数量 ,或 者 搜索 的 深度 达到 了 dbwr scan depth 的 值 
( 该 参数 在 数据 库 运 行 过 程 中 会 自动 调整 ， 调 整 范 围 在 min scan depth fll max scan depth 之 间 )。 
扫描 结束 后 ，known clean buffer 的 值 被 重 置 为 DBWR 扫描 后 的 clean buffers scanned 的 值 与 本 次 
dbwr write batch 写 和 人 的 缓冲 区 数 的 总 和 。 此 时 ，LRU 门 锁 被 释放 ， 然 后 DBWR 将 及 数据 块 写 人 
数据 文件 ， 并 将 已 经 写 入 的 缓冲 区 放 入 LRU-AUX 链 。 

如 果 DBWR 写 入 完成 后 ，LRU-W 链 空 了 ， 或 者 known clean buffer count 已 经 大 于 dbwr scan 
depth 的 3/4, 那么 dowr scan depth 将 被 减少 一 个 增 量 。 因 为 系统 认为 DBWR 的 写 操作 总 量 可 以 
略微 降低 。 如 果 写 人 后 ,known clean buffer count 还 小 于 dbwr scan depth 的 1/2 ,那么 dbwr scan depth 
会 增加 一 个 增 量 ， 因 为 系统 认为 DBWR 的 写 操作 总 量 需要 增加 。 

除了 Make Free Message 外 ， 还 有 其 他 的 消息 可 以 唤醒 DBWR ， 最 为 典型 的 是 Checkpoint 消 
息 和 Reuse Block Range 消息 。Reuse Block Range 可 能 由 drop. truncate 等 ddl 命令 发 出 。 此 外 每 
隔 3 秒 钟 ， 会 产生 一 个 DBWR timeout $F, WR DBWR 发 现 休 眼 超时 后 ，LRU-W 还 是 空 的 ， 
那么 它 就 会 以 两 倍 于 dbwr scan depth 的 深度 搜索 LRU-W ， 寻 找 脏 数据 块 。 

本 节 介 绍 了 DBWR 的 一 些 基 本 算法 ， 这 些 算法 是 以 Oracle 8i 的 基础 版 本 为 对 象 的 ， 其 实 我 
们 学 习 这 些 算 法 的 目的 并 不 是 为 了 写 一 套 新 的 RDBMS 管理 软件 ， 而 是 从 中 理解 一 些 DB Cache 
和 DBWR 的 配置 、 优 化 、 维 护 方 面 的 思路 。 在 随后 的 几 节 中 ， 我 们 将 逐步 展开 讨论 这 些 内 容 。 


2.2.1 DB WRITER PROCESSES 参数 


对 于 绝 大 多 数 系统 来 说 ， 只 要 IO 能 力 足 够 强 ， 并 且 DB Cache 容量 足够 大 ， 那 么 在 一 般 情 
况 下 ， 单 个 DBWR 进程 基本 上 是 能 够 胜任 的 。 不 过 对 于 VO 十 分 敏感 的 系统 或 者 并 发 量 十 分 巨 
大 的 系统 ， 使 用 多 个 DBWR 进程 有 助 于 提高 脏 数 据 块 写 的 性 能 。Oracle 7 虽然 也 支持 多 个 DB 
WRITER 进程 ， 但 是 这 些 进 程 之 间 是 有 区 别 的 ， 其 中 一 个 是 MASTER ， 其 他 几 个 是 SLAVER, 
SLAVER 进程 是 不 能 使 用 异步 UO 的 ， 只 能 使 用 模拟 的 异步 JO。 从 Oracle 8.0.4 开始 ，DBWR 的 
算法 发 生 了 革命 性 的 变化 。DBA 可 以 使 用 两 种 策略 来 配置 DBWR, 一 种 是 单个 DBWR 进程 加 上 
多 个 IO SLAVER 进程 ;另外 一 种 是 配置 多 个 DBWR 进程 ,不 论 是 使 用 DBWR 还 是 IO SLAVER, 
都 可 使 用 异步 WO。 这 种 改进 大 大 提高 了 数据 库 写 IO 的 性 能 。 

在 使 用 Oracle 8 以 上 的 版 本 时 ， 如何 配 置 DBWR? 是 使 用 多 个 DB WRITER HERE, 还 是 一 个 
DB WRITER 进程 加 上 多 个 IO SLAVER 进程 呢 ? 实际 上 这 两 种 配置 方法 很 难 分 出 优 劣 ,在 不 同 的 
系统 上 ， 可 能 两 种 配置 的 效果 差不多 ,也 可 能 有 所 区 别 。 上 有 具体 使 用 哪 种 方式 ， 只 有 做 过 实验 才能 
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得 到 准确 的 结论 。 十 年 前 ， 关 于 这 两 种 方法 的 优 劣 , 在 网 上 有 过 一 场 论战 , 最终 论战 双方 也 都 无 

法 说 服 对方 。 实 际 上 , 在 当时 的 系统 配置 情况 下 ， 这 两 种 方式 的 主要 区 别 在 于 ， 如 果 使 用 单一 的 

DBWR 进程 加 上 多 个 VO SLAVER 进程 ， 那 么 这 种 配置 和 Oracle 7 的 多 DBWR 进程 的 机 制 是 类 

似 的 ， 不同 的 只 是 SLAVER 进程 支持 异步 VO, H MASTER 的 DBWR 进程 来 管理 LRU 链 和 组 

ZH WRITE BATCH， 而 实际 的 IO 操作 是 由 SLAVER 进程 完成 的 ,MASTER 和 SLAVER 之 间 采 

用 类 似 于 异步 IO 的 机 制 ， 将 写 任务 交 给 SLAVER Jr, MASTER 可 以 继续 进行 下 面 的 操作 ， 从 

而 提高 DBWR 的 处 理 能 

如 果 使 用 多 个 DBWR 进程 ,那么 每 个 DBWR 管理 LRU 链 的 一 个 子 区 域 。 每 个 DBWR 都 有 
自己 的 LRU LATCH ， 对 于 Oracle 8 和 Oracle 8i, LRU LATCH 通过 参数 

DB_BLOCK_LRU_LATCHES 来 设置 ( Oracle 9i 以 后 的 版 本 中 取消 了 这 个 参数 ， 自 动 将 每 个 DB 

Cache 的 LRU LATCH 数量 设置 为 CPU 数量 的 一 半 )。 

DB BLOCK LRU LATCHES 定义 了 所 有 DB Cache 的 LRU LATCH 总 数 。 一 般 来 说 ， 建 议 

将 该 参数 设置 为 不 超过 CPU 的 数量 ( 对 Oracle 8j, DB. BLOCK. LRU. LATCHES 的 最 大 值 为 CPU 

数量 的 6 倍 ), 而 一 般 情 况 下 , DBWR 的 数量 也 不 应 该 超过 DB BLOCK. LRU LATCHES 的 数量 ， 

否则 会 形成 LRU 门 锁 的 竞争 。Oracle 8/8; 对 于 使 用 多 缓冲 的 情况 ,除了 DEFAULT POOL 以 外 ， 

每 个 POOL 的 LATCH 数 量 默认 为 1, 也 可 以 在 DB_BUFFER 参数 中 指定 LATCH 的 数量 ,DEFAULT 

POOL 的 LATCH 数量 是 总 数 减 去 其 他 BUFFER 的 LATCH 数量 。 

随 着 硬件 技术 的 发 展 ， 系 统 拥 有 了 更 多 的 CPU 、 更 大 的 内 存 和 更 快 的 IO FAR. WS, Be 

置 DBWR 不 仅仅 要 考虑 ИО 的 能 力 ， 因 为 现在 的 DB Cache 已 经 不 像 十 多 年 前 那样 ， 几 个 G 就 算 

是 超大 型 的 系统 了 ， 而 是 动 辑 几 十 G 甚至 几 百 G. LRU 的 管理 性 能 成 为 一 个 十 分 重要 的 考虑 因 

素 ， 因 此 由 单个 DBWR 来 管理 LRU 显然 是 不 合适 的 ， 使 用 多 个 DBWR 进程 成 为 主要 的 选择 。 

基于 上 面 关 于 DBWR 的 基础 知识 ， 在 设置 DBWR 数量 的 时 候 ， 我 们 可 以 如 此 考虑 : 

о 一 般 情 况 下 ， 如 果 没 有 发 现 明显 的 DBWR 问题 ， 那 么 不 需要 使 用 多 个 DBWR。 

a 如 果 确 实 需 要 使 用 多 个 DBWR, 那么 对 于 多 CPU 系统 , 一 般 可 以 直接 使 用 ; 对 于 单 CPU 
系统 ， 可 以 采用 一 个 DBWR 加 上 多 个 VO SLAVER 的 方式 。 这 条 经 验 不 是 绝对 的 ， 为 了 
确保 获得 最 佳 的 性 能 ， 最 好 是 两 种 方式 都 尝试 一 下 。 

口 如 果 你 使 用 的 是 9i 或 者 更 高 的 版 本 ， 对 于 VO 不 存在 严重 瓶颈 的 系统 ， 那 么 就 写 不 犹 殉 

地 使 用 多 个 DBWR 吧 。 

口 使 用 多 个 DBWR 时 , 建议 DBWR 的 数量 不 要 超过 CPU 的 数量 ( 对 于 Oracle 8/8i, DBWR 
的 数量 不 超过 DB_BLOCK_LRU_LATCHES )。 

那么 我 们 如 何 来 判断 目前 的 DBWR 是 否 足 够 呢 ?STATSPACK 报告 或 者 AWR 报告 是 十 分 好 

的 工具 。 


Free Writ Buffer 
Number of Pool Buffer Physical Physical Buff Comp Busy 
P Buffers Hit% Gets Reads Writes Wait Wait Waits 


D 4,405,998 98 945,225,805 21,899,493 2,291,122 0 0 5,692,101 
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如 果 经 常会 有 write complete waits 存在 ， 那 么 就 说 明 DBWR 的 写 性 能 不 足 ， 可 以 考虑 通过 
增加 DBWR 来 改善 脏 块 写 的 性 能 。 另 外 ， 在 出 现 free buffer waits 的 问题 时 ， 如 果 我 们 无 法 通过 
扩大 DB Cache 来 改善 其 性 能 ， 那 么 就 需要 增加 DBWR 的 数量 ， 这 样 也 可 以 改善 这 方面 的 问题 。 

最 后 要 强调 的 一 点 是 ,不 要 误解 了 本 节 的 观点 ， 由 于 本 节 介 绍 的 内 容 是 从 Oracle 7 到 现在 的 
11.2 各 个 版 本 的 情况 ,因此 有 些 观点 可 能 更 适合 于 早期 的 Oracle 版 本 。 在 10g 或 者 11g 中 ,大 家 
不 需要 花费 太 多 的 精力 纠结 于 DBWR 的 配置 ， 大 多 数 情况 下 ， 默 认 的 配置 就 没有 问题 。 只 有 人 少 
数 情况 ,我 们 需要 增加 DBWR 的 数量 。 调 整 DBWR 的 数量 是 很 专业 的 操作 ,一 定 要 在 深思 熟 虑 
后 再 去 进行 。 


2.2.2 DB Cache 的 几 个 主要 的 链 和 CKPT 算法 


DB Cache 中 有 很 多 重要 的 链 ， 这 些 链 或 者 和 DB Cache 的 分 配 、 换 出 、 刷 新 优化 有 关 ， 或 者 
fll DB BLOCK 的 查找 有 关 。 下 面 我 们 先 来 了 解 这 些 链 的 基本 情况 , 然后 再 来 探讨 它们 在 各 种 DB 
Cache 活动 中 所 起 的 作用 。 

1. LRU list 和 LRU-AUX list 

LRU list 也 叫 replacement list， 就 是 大 家 常 说 的 LRU 链 ， 我 们 在 前 面 的 章节 已 经 做 了 很 详细 
的 介绍 ,这 里 就 不 多 说 了 。 要 特别 提 到 的 是 LRU-AUX list, 它 是 LRU 链 的 一 条 子 链 。 从 LRU-AUX 
头 开始 的 BLOCK 是 被 确认 为 CLEAR 的 ， 其 来 源 包括 DBWR 已 经 写 回 文件 的 数据 块 和 UNPIN 
的 干净 块 。 前 台 进 程 查找 空间 BUFFER 的 时 候 ， 会 首先 在 LRU-AUX 中 查找 ， 因 为 从 这 里 找到 
的 BUFFER 一 般 都 是 可 用 的 。 

2.LRU-W list (write list) 

LRU-W list 就 是 我 们 常 说 的 脏 数 据 链 , 在 前 面 的 章节 中 , 我 们 已 经 详细 介绍 过 , 对 于 LRU-W 
链 ， 也 存在 一 个 AUX 链 一 一 LRUW-AUX。 引 入 AUX 链 是 为 了 提高 LRU-W 的 效率 ， 支 持 异 步 
DBWR 作业 。 在 没有 引入 这 条 链 以 前 ， 当 一 个 DBWR 作业 还 没有 完成 时 ， 是 无 法 进行 下 一 个 
DBWR 作业 的 。 引 入 AUX Ja, AUX 链 存放 的 是 当前 DBWR 正在 写 入 的 数据 ， 这 样 LRU-W 就 
可 以 腾 出 来 处 理 下 一 个 DBWR 作业 了 。 

3. LRU-XO list (reuse object list) 

LRU-XO list 也 被 称 为 重用 对 象 链 ， 这 条 链 主 要 对 TRUNCATE, DROP 等 操作 对 象 相关 的 
BUFFER 进行 CHECKPOINT 操作 。 当 reuse object cross Instance call 事件 发 生 的 时 候 ，CKPT 会 
将 这 个 对 象 的 脏 数据 块 放 和 LRU-XO 链 ， 然 后 由 DBWR 将 这 些 数据 块 写 盘 。 当 CKPT 发 现 这 条 
链 已 经 为 空 时 ， 本 次 CHECKPOINT 操作 宣告 结束 。 

4. LRU-XR list (reuse range list) 

LRU-XR list 也 被 称 为 Reuse range ВЕ, *^ reuse range cross Instance call 事件 发 生 的 时 候 ,CKPT 
搜索 这 些 BUFFER, ， 将 脏 数据 块 放 和 人 LRU-XR 链 ， 然 后 再 由 DBWR 将 这 些 数据 写 盘 。 当 CKPT 
发 现 这 条 链 已 经 为 空 时 ， 本 次 CHECKPOINT 宣告 结束 。 如 果 我 们 要 将 某 个 表 空 间 OFFLINE 或 
者 将 其 设置 为 READ ONLY， 此 时 就 会 产生 ruse range cross Instance call 事件 ， 因 为 要 想 安全 地 完 
成 这 些 操作 ， 必 须要 将 表 空 间 上 的 脏 数据 全 部 写 人 磁盘 。 
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上 面 介绍 了 一 些 LRU 链 ， 下 面 我 们 再 来 看 看 BUFFER HEAD 的 数据 结构 ， 了 解 一 下 这 些 链 
是 如 何 使 用 的 (代码 清单 2-3 所 示 的 伪 代 码 是 10g 的 BH 的 一 部 分 , 为 了 方便 读者 更 清晰 地 查阅 ， 
这 里 去 掉 了 一 部 分 不 相干 字段 )。 


代码 清单 2-3 
kgglk HASH 链 的 指针 ; 
ktsn 表 空 间 号 ; 
krdba RDBA 地 址 ; 
kobj d Aig OBJ №; / 不 一 定 有 值 *l 
kobjn 字典 08j №; |* 不 一 定 有 值 *| 
ub2 绝对 文件 号 ; 
b1 BUFFER 修改 计数 ; 
ub2 仿真 组 | D; 
ubl # WORKING SET 上 的 CKPT 队列 号 ; 
kgglk ckpt queue 的 链接 指针 ; 
kgglk 文件 CKPT QUEUE 的 指针 ; /* 每 个 文件 都 有 一 个 Ckpt queue, 
在 reuse range 时 使 用 */ 
ptr_t 指向 真正 的 BUFFER 的 指针 ; 
kgglk 正在 使 用 该 BUFFER 的 使 用 者 的 列表 ; 
kgglk 正在 等 待 该 BUFFER 的 列表 ; 
kgglk kcbbhrpl;/* BUFFER 的 LRU 链 指针 *# / 
b1 是 否 在 LRU-W k; /* 如 果 在 LRU-W 上 ， 该 值 为 TRUE* / 
b1 LRU 门 锁 保 护 标 识 ; 
ub2 TCH; 
void * 指向 TX STAT OBJECT 的 指针 ; 
kcocv * 指向 该 BUFFER #9 ж/5 —A- CHANGE $6548 4p; 
struct kcbwds * WORKING SET 的 指针 ; 
krfgda kcbbhgda; /* 闪 回 数 据 的 磁盘 地 址 *| 
kggl k kcbbhoq; /* 对 象 CKPT QUEUE 的 指针 ， 在 REU9E OBJECT 时 使 用 */ 


根据 上 面 的 数据 结构 , 接 下 来 我 们 要 推测 CKPT 操 作 了 。 以 前 经 常 有 人 问 我 CKPT 的 相关 操 
作 ， 我 在 这 方面 的 研究 较 少 ， 主 要 是 因为 相关 的 Oracle 文档 实在 是 太 少 了 。 虽 然 从 Tom 和 Steve 
那里 可 以 获得 一 些 资料 , 但 是 都 比较 细碎 ， 因 此 针对 CKPT 操作 的 一 些 细节 问题 , 我 也 只 能 通过 
上 面 的 数据 结构 做 一 个 推测 , 这 个 推测 不 一 定 准 确 , 不 过 大 体 上 可 以 反映 出 CKPT 算法 的 一 些 最 
基本 的 概念 。 

首先 ， 我 们 来 看 看 CHECKPOINT QUEUE。 它 是 通过 LOW RBA 排序 的 一 个 链表 ， 当 某 个 
BLOCK 发 生变 化 的 时 候 ， 会 将 该 BLOCK 按照 LOW RBA 地 址 链 入 相关 的 CHECKPOINT 
QUEUE， 这 些 链 表 包 括 标 准 CKPT QUEUE ( 老 白 在 这 里 用 了 “标准 ”二 字 ， 实 际 上 这 并 不 是 
Oracle 内 部 的 术语 ， 这 部 分 内 容 公布 的 很 少 ， 因 此 这 里 只 是 为 了 将 其 区 别 于 RANGE 和 OBJECT 
这 两 个 CKPT QUEUE ), XO CKPT QUEUE( OBJECT CKPT, 每 个 对 象 一 个 ) 和 XR CKPT QUEUE 
(RANGE CKPT， 术 语 称 为 PER-FILE CKPT QUEUE ， 每 个 数据 文件 一 个 )。 

在 进行 普通 的 CHECKPOINT 操作 时 ,CKPT 进程 先 找 到 CKPT 链 的 头 部 , 将 CKPT QUEUE 
交 给 DBWR， 再 由 DBWR 组 织 CHECKPOINT DBWR 批 处 理 ， 然 后 DBWR 进程 开始 写 入 操作 ， 
由 于 CKPTQUEUE 是 按照 LOW КВА 的 顺序 排序 的 , 因此 在 做 CHECKPOINTDBWR 批 处 理 时 ， 
要 按照 ВВА 的 顺序 写 人 腑 数据 。 在 DBWR 完成 写 操作 后 ，CKPT 进程 更 改 控制 文件 和 相关 文件 
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头 的 SCN 数据 ， 记 录 本 次 CKPT 操作 的 结果 。 

由 于 CKPT QUEUE 上 的 BUFFER 有 可 能 在 LRU 链 上 ， 也 有 可 能 在 LRU-W 链 上 ， 在 组 织 
DBWR 批 处 理 时 , LRU 链 上 的 BUFFER 2279 224i) PRCA LRU-W? 这 些 算法 在 CHECKPOINT 写 
和 人 的 时 候 ，BLOCK 不 从 LRU LIST 上 移 走 ， 写 完 后 ， 从 CKPTQ 里 清除 ， 这 和 普通 的 LRUW 中 
的 块 被 写 人 数据 库 是 不 同 的 。 

在 进行 TRUNCATE, DROP 这 类 操作 时 ， 也 会 发 生 CHECKPOINT， 这 类 CHECKPOINT 被 
称 为 REUSE OBJECT CHECKPOINT ,具体 的 操作 细节 目前 很 少 有 资料 说 明 。 老 白 猜 测 , 当 REUSE 
OBJECT CHECKPOINT 发 生 时 ，CKPT 进程 将 kcbbhoq 指向 的 OBJECT CHECKPOINT 链 上 的 脏 
块 链 入 LRU-XO , 交 给 DBWR 处 理 JDBWR 组 织 写 批 处 理 , 进 行 写 人 操作 。 只 有 当 所 有 的 LRU-XO 
上 的 块 全 部 被 写 入 后, DDL 操作 才能 完成 。 这 种 算法 在 用 TRUNCATE 拼接 一 个 大 对 象 时 可 能 会 
很 慢 ( 如 果 这 个 对 象 有 很 多 脏 块 的 话 )。10sg 的 kcbbhoq 字段 是 一 个 对 象 的 BUFFER 链 。 这 条 链 
的 存在 对 于 reuse object cross Instance call 的 性 能 有 很 大 的 帮助 。 

当 表 空间 设置 为 READ ONLY 或 者 OFFLINE 的 时 候 ， 会 触发 REUSE RANGE 的 
CHECKPOINT， 其 原理 和 REUSE OBJECT 的 CHECKPOINT 类 似 。 通 过 在 BUFFER HEAD 中 的 
kcbbhfql 将 每 个 数据 文件 的 脏 块 串 成 一 条 链 。 这 样 ， 当 REUSE RANGE CHECKPOINT 发 生 时 ， 
CKPT 将 这 条 链 链 人 LRU-XR， 然 后 交 给 DBWR 处 理 。 


2.2.8 RARA DB BLOCK 的 模拟 算 ; 


很 多 朋友 都 在 研究 检索 数据 块 的 内 部 算法 , 不 幸 的 是 Oracle 公司 并 没有 公开 这 个 算法 , 而 且 
这 是 Oracle 数据 库 性 能 的 最 核心 技术 之 一 , 这 部 分 算法 是 永远 也 不 可 能 公开 的 。 老 白 根据 这 些 年 
对 Oracle 内 部 原理 的 研究 ， 编 写 了 一 段 伪 代码 ， 通 过 这 段 伪 代码 向 各 位 读者 展示 一 下 DB Cache 
管理 的 一 些 算法 细节 。 这 段 伪 代 码 只 能 够 模拟 DB Cache 管理 的 一 些 皮毛 , 在 具体 的 实现 细节 上 ， 
Oracle 的 内 部 原理 要 复杂 得 多 。 下 面 我 们 就 来 看 看 这 段 伪 代码 ， 如 代码 清单 2-4 所 示 。 


代码 清单 2-4 


mai n() 
{ 
int vRDBA; 
| | 获取 该 数据 块 的 HASH 链 的 散 列 值 
v_hash_value=getRdbaHash(vRDBA); 
IISPIN 相关 cache buffers chains, 根据 散 列 值 选择 不 同 的 子 门 锁 
while (!spinLatch (‘cache buffers chains',v hash value]) 
{ 
|| 如 果 Spin kW, sleep, REE SPIN 
pinLatchSleep(sleepTi me++); 
} 
|| 在 指定 的 hash chains 中 查找 符合 某 个 3CN 条 件 的 数据 块 的 BUFFER HEAD 
retVal -findBufferlnHashChai ns(v hash value, vRDBA, vScn,); 


if(retVal 220. 找到 兼容 版 本 数据 
| | 如 果 找 到 了 兼容 的 版 本 的 DB Cache 数据 ， 那么 通过 BH 中 的 指针 找到 这 个 Cache 的 地 址 ， 
|] 然后 将 该 地 址 写 入 UGA 的 访问 该 数据 块 的 库 缓 存 的 访问 数据 块 列 表 中 
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{ 

/11Vvkcbh 是 这 个 buffer 的 buffer head， 这 个 bh 被 链接 在 HASH CHAINS k, 
11kcbbhba 是 BH 对 应 的 BUFFER 的 地 址 

vksuse->ksusesql->...=vkcbh->kcbbhba; 
|| 释放 [Cache buffers chains 门 锁 ， 然 后 返回 ， 结 束 访 问 
unpinLatch('cache buffers chains',v hash value); 
return; 

} 

else 
{ 


if(retVal ==(0_ 找到 BUFFER| | 0_ 当前 快 | | 0_SCN ЖЖЖ) 
II 需要 生成 CR BLOCK, ЖЕ 


Il 释放 Cache buffers chains 门 锁 ， 然 后 返回 ， 结 束 访问 
unpinLatch('cache buffers chains',v hash value); 

ГІ 查找 一 个 空闲 的 BUFFER， 用 于 生成 CR block 
[| 查找 空闲 块 ， 将 起 buffer head 赋予 Vbh ， 如 果 找 不 到 ， 反 复 重 试 
while((vbh=findFreeBuffer())==null) 


|] 如 果 没 有 找到 空闲 块 ， 发 出 makefree 消息 ， 然 后 SLEEP ， X ER 
sendMakeFreeMsg(); 
sleepForFreeMsg(); 
} 
[| 再 次 获取 相关 Cache buffers chains, 根据 散 列 值 选择 不 同 的 子 门 锁 
while (!spinLatch (‘cache buffers chains',v hash value)) 
{ 
l| 如 果 Spin kik, sleep, Eak SPIN 
pinLatchSleep(sleepTi me++) ; 


} 
/11 下面 操作 省 略 ， 算 法 十 分 复杂 ， 先 复制 CURRENT 的 BUFFER 到 新 BUFFER， 
|] 然后 通过 UNDO 数据 前 滚 数 据 块 的 数据 
[1 处 理 完 成 , 释放 Cache buffers chains 门 锁 ， 然 后 返回 
unpinLatch('cache buffers chains',v hash value); 
return; 
} 
} 
else 
|] 没有 找到 BUFFER ， 找 一 个 可 用 的 BUFFER， 从 数据 文件 读 入 相关 BLOCK 


{ 
I| 释放 [Cache buffers chains 门 锁 ， 然 后 返回 ， 结 束 访 问 
unpinLatch('cache buffers chains',v hash value); 
|] 查找 一 个 空闲 的 BUFFER ， 用 于 读 取 数 据 块 
|] ERZAR, buffer head 赋予 vbh ， 如 果 找 不 到 ， 反 复 重 试 
while((vbh=findFreeBuffer())==null) 
{ 
11 如 果 没 有 找到 空闲 块 ， 发 出 makefree Ha, 然后 9LEEP， 等 待 唤醒 
sendMakeFreeMsg(); 
sleepForFreeMsg(); 


} 
|] 再 次 获取 相关 Cache buffers Chains ， 根 据 散 列 值 选择 不 同 的 子 门 锁 
while (!spinLatch (‘cache buffers chains',v hash value)) 
{ 
l| 如 果 Spin 失败 ， 就 5S|eep ， 然 后 继续 9PIN 
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pinLatchSleep(sleepTi me++); 
} 
/1 下面 省 略 ， 从 数据 文件 中 读 取 该 数据 块 


|| 处 理 完成， 释放 [Cache buffers chains 门 锁 ， 然 后 返回 
vksuse->ksusesql->...=vkcbh->kcbbhba; 
LI 以 下 省 略 ， 从 数据 块 中 查找 所 需要 的 记录 


unpinLatch('cache buffers chains',v hash value); 
return; 
} 
} 


上 面 这 段 代 码 是 老 白 随手 涂鸦 之 作 ， 可 能 和 Oracle 实际 的 算法 相去 甚 远 。 不 过 它 体现 出 了 
Oracle DB Cache 操作 的 一 些 基 本 的 原理 性 规则 ， 大 家 可 以 参考 。 在 访问 某 个 数据 块 时 ， 首 先 要 
计算 出 该 数据 块 的 散 列 值 , 然后 获取 该 HASH ВЕНН Я, 再 去 搜索 HASH CHAINS。 搜索 的 
时 候 不 仅 要 找到 RDBA 一 致 的 数据 块 , 而且 其 SCN 也 要 符合 要 求 ， 如 果 SCN 不 符合 要 求 , 那么 
可 能 需要 生成 CR 块 ， 再 从 CR 块 中 读 取 相关 数据 。 

这 部 分 的 知识 点 十 分 丰富 , 而 且 和 很 多 知识 点 都 有 关联 和 交 又 ,因此 老 白 这 段 代码 只 是 考虑 
了 最 为 简单 的 场景 。 如 果 大 家 有 兴趣 ， 可 以 继续 细 化 这 段 代码 ， 从 而 更 深入 地 理解 这 些 知识 点 。 

这 部 分 相关 的 知识 点 包括 : working set(x$kcbwds)、DB BLOCK (包括 数据 文件 、 表 空间 、 
extent, segment 等 )、buffer head(x$bh) hash chains, lru chains 、undo 、 会 话 和 PGA 等 。 

K 2-2 演示 了 从 数据 文件 读 取 一 个 数据 块 到 DB Cache 的 简单 过 程 , 这 是 老 白 在 参考 了 Poder 
的 讲义 后 所 模仿 的 。 


表 2-2 
操 E 门 锁 等 待 其 他 等 待 CPU 时 间 说 8H 
读 取 (10/2512) 

get_latch('cache buffer chains'):spin 1 获得 门 锁 以 便于 查找 数据 
搜索 buffer chain 5 查找 所 需 数据 
db_file_sequential_read 等 待 5 正常 的 IO 时 间 
get_latch('cache buffer Iru chains'):spin 10 ARAB 
get latch('cache buffer Iru chains'):sleep 10 苞 取 不 到 ， 休 眼 
get_latch('cache buffer Iru chains'):spin 10 继续 获取 
get_latch('cache buffer Iru chains'):sleep 20 再 次 休眠 
get_latch('cache buffer Iru chains'):spin 5 РА: ЕНШЕ 
查找 可 用 DB BUFFER 3 
写 和 人 数据 1 
get_latch('cache buffer chains'):spin 2 获取 门 锁 以 便 将 cache 链 入 


30 5 37 


48 第 2 章 理解 DB Cache 


2.3 DB Cache 相关 的 参数 门 锁 和 等 待 事件 


本 节 将 介绍 和 DB Cache 相关 的 数据 库 参 数 、 等 待 事件、 系统 统计 信息 、 门 锁 和 相关 诊断 视 
图 等 内 容 。 目 的 是 让 读者 能 够 对 DB Cache 及 相关 的 数据 库 组 件 有 一 个 总 体 的 认识 。 由 于 篇 幅 的 
关系 ， 本 节 仅 对 这 些 参数 和 等 待 事件 做 简单 的 介绍 

DB Cache 相关 的 参数 如 表 2-3 所 示 。 


表 2-3 
参数 名 称 参数 简介 Sk ik 值 
db cache size db keep cache size ”从 9i 开 始 ， 设 置 DB Cache 大 小 的 参数 。db_cache_size 是 默 ”10g,11g 默 认 值 为 
db_recycle_cache_size 认 池 的 大 小 ，db_keep_cache_size 是 keep pool 的 大 小 ， 0 (使 用 自动 共享 


P E E size d e 5122 ДЬ recycle cache sizeldirecycle pool 的 大 小 。 从 9i 开 始 还 支 ”内 存 管理 ) 
TAX cache ege 持 非 标准 大 小 的 表 空 间 ， 针 对 每 种 非 标准 大 小 的 表 空 间 ， 


需要 设置 相应 的 db_nk_cache_size 参 数 。 本 参数 的 单位 为 字 
“4; 
db block buffers Биҝег pool keep ”9i 以 前 版 本 的 DB Cache 设 置 参数 ， 在 Windows 32 位 环境 下 
n pool tecyele f#JH3GJF RAIRE, ona E Ы а ЗЕ E ЯН AU, A 
参数 的 单位 为 块 
db_block_size 数据 块 大 小 (9i 以 前 ) 或 者 标准 数据 块 大 小 (9i 及 以 后 版 8 KB 
本 ) 
db_cache_advice 从 9i 开 始 引 入 的 参数 ，db_cache 建 议 的 开启 开关 ， 如 果 设 ON 
为 ON， 可 以 看 到 db_cache 建 议 数据 
db_block_checking 当 数 据 块 变 更 (UPDATE, INSERT) 时 ， 从 磁盘 上 读 取 或 ”OFF/FALSE 


A INTERCONNECT fet 时 进行 逻辑 一 致 性 的 校 验 。 该 
参数 启用 后 会 减少 数据 块 内 存 损 坏 或 者 出 现 逻 辑 故 障 的 
可 能 性 ， 不 过 会 带 来 1%~10% 的 额外 系统 负载 。 数 据 安全 
性 要 求 高 而 且 负 和 载 不 大 的 系统 可 以 使 用 ， 一般 系统 不 建议 
使 用 。 该 参数 控制 的 是 用 户 表 空间 的 数据 块 ， 对 于 系统 表 
空间 的 数据 块 ，Oracle 是 必须 进行 块 检查 的 。11g 的 取 值 范 
El: OFF, FALSE, LOW, MEDIUM, FULL, TRUE, 10g 
R2 的 取 值 范围 : OFF, LOW, MEDIUM, FULL, 10g Rl, 
9i 的 取 值 范围 : TRUE, FALSE 


db_block_checksum 控制 是 否 对 数据 块 生 成 和 校 验 checksum 值 。 这 个 参数 仅 控 10g R2 及 更 高 版 
制 用 户 表 空间 的 数据 块 。 对 于 10g R2 及 更 高 版 本 ， 这 个 参 “ Ж: TYPICAL, 
数 的 值 是 STRING 类 型 , 取 值 包 括 OFF (不 生成 checksum) 、 早期 版 本 : TRUE 
TYPICAL ( 仅 在 数据 读 入 和 写 人 时 生成 和 校 验 checksum， 
可 能 带 来 1%~2% 的 额外 负载 ) 以 及 FULL (在 数据 变化 时 
生成 和 校 验 checksum， 可 能 带 来 5% 左 右 的 额外 负载 ) ， 默 
认 值 为 TYPICAL。 10g R2 以 前 的 版 本 , 该 参数 是 布尔 型 的 ， 
默认 值 是 TRUE， 和 TYPICAL 类 似 


_db_block_Iru_latches 定义 LRU 门 锁 的 数量 ， 一 般 情况 不 建议 修改 

_db_block_hash_buckets db_cache 的 hash 链 的 数量 ， 一 般 情 况 不 建议 修改 

_db_block_hash_latches db_cache 的 hash 链 的 门 锁 的 数量 ， 一 般 情况 不 建议 修改 

db_writer_processes db_writer 进 程 的 数量 10g 及 更 高 版 本 :1 


或 l/cpu_count。9i 
默认 值 为 1 
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( Ж) 
参数 名 称 参数 简介 Sk GA {Н 
db file multiblock read count 这 个 参数 在 108 之 前 需要 设置 ， 控 制 全 表 扫 描 或 全 索引 扫描 MRE; 10g 


每 次 读 取 的 数据 块 的 最 大 值 。 针 对 OLAP 系 统 ， 这 个 参数 设 ”开始 采用 自动 
置 略 高 ，OLTP 系 统 ， 一 般 默 认 值 就 可 以 了 。10g 以 后 , 数据 ”调整 , 默认 是 自 
库 会 根据 MO 情况 自动 调整 ， 不 需要 人 工 干 预 。118 即 使 设置 ” 动 调整 

了 ， 系 统 也 不 会 采用 。9; 和 及 之 前 版 本 ， 设 置 该 参数 时 要 十 

分 注意 ， 因 为 SQL 执行 计划 中 计算 开销 与 它 有 关 ， 如 果 设 置 

较 大 的 值 ， 优 化 器 计算 全 表 扫 描 的 时 候 成 本 会 降低 


DB Cache 相关 的 等 待 事件 如 表 2-4 所 示 。 


表 2-4 
等 待 事件 名 称 说 — BH 

buffer busy waits; read by another ” 热 块 冲突 产生 的 等 待 。 从 10g 开 始 引 入 了 read by another session 这 个 独立 的 等 待 事 

session 件 ， 是 buffer busy waits 中 的 一 个 特殊 情况 

free buffer waits 前 台 进 程 无 法 找到 可 用 的 buffer， 等 待 free buffer。 如 果 等 待 时 间 较 长 ， 说 明 DB 
Cache 可 能 不 足 

checkpoint completed 等 待 checkpoint 完 成 

write complete waits 前 台 进 程 等 待 DBWR 完 成 写 和 后 查找 可 用 buffer， 如 果 等 待 时 间 较 长 ， 说 明 DB 
Writer 的 性 能 不 足 ， 或 者 DB Cache 太 小 


DB Cache 相关 的 部 分 统计 数据 如 表 2-5 所 示 。 


表 2-5 
名 称 说 BB 
consistent changes 数据 块 提 交 了 undo 信 息 成 为 CR 块 的 计数 。 这 个 值 说 明了 系统 中 CR 块 产生 的 数量 。 
该 值 越 大 ， 越 要 注意 cache buffers chains 等 门 锁 的 情况 以 及 热 块 对 系统 性 能 的 影响 
consistent gets 一 致 性 读 的 计数 。 会 话 发 出 的 对 某 个 数据 块 进行 一 致 性 读 的 请 求 。 不 能 将 其 与 
consistent changes 混 消 。 一 个 CR 块 产生 后 ， 可 能 被 多 个 consistent gets 事 件 调 用 ， 基 


此 该 值 要 比 前 一 个 值 大 得 多 
data blocks consistent reads - undo ”从 undo 中 读 取 数据 ， 形 成 CR Read。 本 计数 器 记录 从 undo 中 获取 undo 记 录 的 数量 。 


records applied 如 果 这 个 值 较 大 ， 说 明 对 于 某 些 修改 较为 频繁 的 表 的 查询 和 其 他 操作 也 很 频繁 ， 
有 可 能 存在 热点 表 和 索引 

dirty buffers inspected 当 某 个 会 话 在 LRU 链 的 冷 端 开始 查找 空闲 的 数据 块 时 查 到 一 个 脏 块 ， 这 个 值 就 会 
曾 加 。 如 果 单 位 时 间 内 该 值 较 大 ， 说 明 LRU 链 的 冷 端 存在 较 多 的 脏 块 。 出 现 这 种 


情况 有 以 下 几 种 可 能 : (1) 系统 中 的 脏 块 数量 十 分 巨大 , 而 且 DBWR 的 写 入 速度 
不 足 ， 导 致 无 法 尽快 将 这 些 脏 块 写 入 硬盘 ， (2) 部 分 buffer 特 别 热 ， 并 且 被 更 改 
的 频率 特别 高 ， 从 而 导致 LRU 链 的 尾 端 存 在 大 量 这 样 的 块 ， (3) 本 系统 是 一 个 以 
DWI 为 主 的 系统 ， 数 据 块 的 变更 十 分 频繁 。 碰 到 这 种 情况 ， 可 以 关注 一 FDBWR 
的 性 能 、DB Cache 的 命中 率 及 cache buffers chains 等 门 锁 的 情况 
DBWR buffers scanned 当 某 些 触发 条 件 发 生 时 ，DBWR 会 在 LRU 链 的 冷 端 扫描 脏 块 ， 组 成 DBWR batch, 
这 个 值 统计 的 是 DBWR 在 LRU 上 扫描 的 buffer 的 总 数 ， 包 括 脏 块 和 干净 的 块 。 这 个 
直 除 以 DBWR LRU scans 就 是 每 次 扫描 查找 的 数据 块 的 数量 
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CE) 
名 称 说 BB 

DBWR checkpoint buffers ”检查 点 时 DBWR 写 入 的 脏 块 的 数量 。 如 果 在 单位 时 间 里 这 个 值 比较 大 , 说 明 系 统 中 数 

written 据 块 的 变更 较为 频繁 

DBWR free buffers found DBWR 从 LRU 链 中 扫描 buffer 时 发 现 的 空闲 buffer 的 数量 。 该 值 除 以 DBWR make free 
requests 就 是 每 次 DBWR 在 收 到 DBWR make free 消 息 时 , 扫描 LRU 链 找到 的 空闲 buffer 
的 平均 数 。 这 个 平均 数 一 般 会 比较 少 

DBWR make free requests DBWR 收 到 的 make free 消 息 的 数量 。 如 果 某 个 前 台 进 程 无 法 找到 空 闻 的 buffer， 就 会 


DBWR summed scan depth 


DBWR timeout 


DBWR transaction table writes 


DBWR undo block writes 
buffer deadlock 


buffer is not pinned count 


buffer is pinned count 


exchange deadlocks 


free buffer inspected 


hot buffers moved to head of 
LRU 


physical reads direct 


physical writes direct 


physical writes non checkpoint 


pinned buffers inspected 


remote Instance undo block 


writes 


向 DBWR 发 出 make free 消 
DBWR 扫 描 LRU 链 查找 脏 


的 热 块 比较 多 ， 也 可 能 造成 这 个 值 较 大 
超过 一 个 特定 值 
据 变化 较 小 ， 需 要 写 入 磁盘 的 脏 块 数量 极 少 


DBWR idlej 


从 Oracl 


息 。 如 果 单 位 时 间 内 这 个 值 较 高 ， 说 明 DB Cache 可 能 不 足 


块 时 ， 查 找 的 buffer 的 数量 。 这 个 数 越 大 ， 说 明 LRU 链 尾部 
e 8i 开 始 ，LRU 链 的 算法 发 生 了 变化 ， 所 以 如 果 LRU 链 尾部 


， 该 值 就 会 加 1。 如 果 该 值 较 高 ， 说 明 buffer cache 中 的 数 


DBWR 写 入 的 回 深 端 头 的 数量 。 该 值 较 高 说 明 有 较 多 的 热 块 正在 被 写 入 , 而 大 量 用 户 
进程 在 等 待 这 些 块 写 入 完成 
DBWR 写 入 回 深 段 的 数据 块 数量 


DB Cache 死 锁 的 数量 。 如 果 单 位 时 间 内 该 值 较 高 ， 可 能 


者 存在 某 些 bug 


被 访问 时 已 经 释放 的 buffer 的 数量 。 
已 经 被 pin 住 了 的 buffer 的 数量 。 如 果 单 


被 访问 时 
在 热 块 


当 进行 两 个 buffer 交 换 时 ， 发 生 内 部 死 锁 的 时 


素 。 如 果 该 值 较 高 ， 可 以 检查 是 否 存 在 十 分 热 的 索引 


DB Cache 存 在 性 能 问题 ,或 


只 用 于 Oracle 内 部 调试 ， 并 不 说 明 性 能 问题 
位 时 间 内 这 个 值 比较 高 , 说 明 可 能 存 


[ 数 。 索 引 扫 描 是 导致 这 种 交换 的 唯一 因 
可 以 通过 buffer busy waits 分 析 


来 定位 ) 

从 LRU 队 列 的 尾部 扫 摘 可 重用 的 buffer 时 跳 过 的 buffer 的 数量 

当 一 个 热 块 到 达 LRU 队 列 的 尾部 时 ，Oracle 会 自动 把 这 个 热 块 移动 到 LRU 队 列 的 头 
部 ,使 之 能 够 继续 被 使 用 。 每 发 生 一 次 这 样 的 操作 ， 这 个 计数 就 加 1。 值得 注意 的 是 ， 
从 Oracle 8 开始，LRU 的 算法 发 生 了 变化 ， 通 过 引入 TCH 计 数 来 确定 热 块 ， 而 不 是 通 
过 将 热 块 在 LRU 链 上 移动 来 保证 热 块 不 被 过 早 地 换 出 。 如 果 热 块 存在 于 LRU 链 的 尾 
部 ， 扫 描 时 发 现 了 热 块 会 主动 地 跳 过 ， 从 而 保证 热 块 不 被 过 早 地 重用 。 


直接 物理 读 的 数量 。 读 时 不 经 过 buffer。 一 
行 查询 操作 的 从 属 进程 或 者 预 读 

直接 写 的 数量 。 不 经 过 buffer， 直 接 写 入 。 
作 ， 比 如 CREATE TABLE AS SELECT; 并行 DWL 操 作 ， 
BA; 写 入 没有 缓冲 的 LOB 字 段 

的 物理 写 。 物 理 写 发 生 的 | 
可 用 , 或 者 DBWR 超 时 等 。 
除非 是 checkpoint 十 分 频繁 的 系统 。 如 果 该 值 占 physical writes 的 比重 比较 少 ， 


jEcheckpoint5 |g 


行 分 析 


当 一 个 用 


计数 器 就 会 增加 


户 进程 扫描 replacement 列 表 , 寻找 可 重用 
或 者 有 一 个 pin 请 求 的 等 待 事件 。 这 种 情况 很 少 发 生 ， 
均 每 秒 该 值 较 大 ， 需 要 进行 分 析 

如 果 远 程 实例 需要 读 取 某 个 undo 块 ， 需 要 这 个 实 


役 发 生 这 种 操作 的 情况 有 : 排序 操作 、 并 


一 般 发 生 


这 种 操作 的 情况 有 : 直接 装载 操 
排序 操作 中 的 临时 表 空 间 


博 况 包括 checkpoint、 无 足够 的 空 闲 buffer 
一 般 情况 下 ， 这 个 值 会 超过 physical writes 的 一 半 以 上 ， 
应 该 进 


的 buffer 时 ，, 发 现 一 个 冷 块 被 pn 了 ， 
因为 冷 块 很 少 会 被 pin。 如 果 平 


“ 脏 的 ”undo 块 


п 


侈 号 ,该 


先 将 这 个 
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( 续 ) 
名 Ж 说 HH 
remote Instance undo header writes 和 上 一 个 值 类 似 ， 只 是 写 入 的 是 undo header 
remote Instance undo requests 由 于 要 做 CR 而 从 远程 实例 中 请 求 undo 的 数量 。 如 果 这 个 值 较 大 , 说 明 RAC 中 的 某 


些 数据 块 经 常 在 实例 间 共 享 ， 某 个 实例 修改 过 的 数据 也 在 被 其 他 实例 使 用 。 这 种 
情况 下 ， 需 要 留意 CLUSTER INTEROBJECT 的 性 能 


recovery array read time 恢复 时 产生 的 IO 消耗 的 时 间 
recovery array reads 恢复 时 产生 的 IO 的 次 数 
Tecovery blocks read 恢复 时 读 取 的 数据 块 的 数量 


write clones created in background ”如果 当前 的 buffer 正 在 被 写 入 ， 那 么 后 台 进 程 或 者 前 台 进 程 克 隆 一 个 新 的 buffer， 
使 原来 的 buffer 的 写 入 可 以 继续 进行 


DB Cache 相关 的 门 锁 如 表 2-6 所 示 。 


表 2-6 
名 Ж 说 BH 

cache buffer handles 果 护 访问 cache 的 handle 的 数据 结构 的 门 锁 , 一 般 情况 下 这 个 门 锁 很 少 出 现 
严重 的 争 用 

cache buffers chains 保护 hash 链 的 数据 结构 的 门 锁 ， 当 buffer 扫 描 的 时 候 会 用 到 该 站 锁 。 该 门 
锁 争 用 的 主要 原因 是 热 块 或 者 热 链 

cache buffers lru chain 保护 LRU 链 数据 结构 的 门 锁 。 当 查找 空 闲 buffer 的 操作 很 频繁 时 ,DB Cache 
容量 不 足 的 时 候 该 门 锁 争 用 会 比较 严重 

checkpoint queue latch 保护 checkpoint queue 数 据 结构 的 门 锁 

simulator hash latch; simulator lru latch 从 9i 开 始 , 数据库 提供 了 DB Cache 建 议 功 能 , 该 建议 可 以 模拟 在 各 种 大 小 
的 DB Cache 下 系统 产生 的 物理 读 的 情况 。 为 了 实现 这 种 功能 ，Oracle 使 用 


了 一 个 专门 的 缓冲 池 , 用 于 模拟 计算 使 用 , 这 两 个 门 锁 就 是 保护 模拟 池 的 
数据 结构 的 。 当 某 个 buffer 操 作 产生 时 , 会 在 模拟 池 中 记录 这 些 信 息 。DB 
Cache 建 议 的 功能 会 带 来 一 些 额 外 的 系统 开销 ， 严 重 时 会 引起 DB Cache 相 
关 的 性 能 问题 


2.4 DB Cache 优化 的 一 些 探讨 


在 前 面 三 节 中 我 们 探讨 了 一 些 关 于 DB Cache 的 算法 ， 探 讨 算法 并 不 是 最 终 的 目的 ， 实 际 上 
我 们 更 为 关注 的 是 DB Cache 的 一 些 内 部 算法 能 够 为 优化 工作 带 来 什么 帮助 。 理 解 DB Cache 的 
基本 原理 对 于 我 们 优化 热 块 冲突 等 问题 具有 十 分 重要 的 意义 。 


2.4.1 DB Cache 和 热 块 冲突 


在 大 家 磁 到 cache buffers chains 门 锁 竞 争 时 ， 可 能 都 会 想到 热 块 争 用 (HOT BLOCK )， 其 实 
不 尽 然 。 正 如 我 们 前 面 几 节 所 讨论 的 ，cache buffers chains 是 串联 DB Cache 的 Hash $£, mi Hash 
链 是 和 数据 块 缓冲 的 寻 址 有 关 的 。 当 某 个 数据 块 被 装载 到 DB Cache 中 的 时 候 ， 系 统 会 根据 DBA 
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的 散 列 值 (DBA 由 数据 块 的 文件 号 和 块 号 组 成 ， 长 度 为 32 字 节 ， 其 中 前 10 个 字 节 为 文件 号 ， 
后 面 22 个 字 节 为 块 号 )， 找 到 一 个 Hash 链 ， 获 取 要 访问 这 个 Hash 链 的 cache buffers chains 子 门 
锁 , 然后 把 Buffer Head 连接 到 这 个 Hash 链 中 。 如 果 要 查找 某 个 数据 块 , 系统 也 会 首先 根据 DBA 
的 散 列 值 找到 这 个 Hash ВЕ, 然后 在 链 上 搜索 。 因 此 ， 如 果 出 现 严 重 的 热 块 冲突 ， 那么 有 可 能 会 
导致 cache buffers chains 门 锁 的 竞争 ， 但 是 门 锁 竞 争 并 不 一 定 都 是 由 热 块 冲突 所 导致 的 ， 至 少 还 
有 两 种 情况 可 能 导致 cache buffers chains 争 用 。 

其 中 一 种 情况 是 数据 库 在 某 个 时 段 出 现 了 大 量 的 数据 块 扫 描 操 作 ( 比如 大 量 的 对 大 表 的 全 表 
扫描 操作 ), 那么 对 于 cache buffers chains 门 锁 的 争 用 将 会 十 分 严重 。 这 种 情况 下 ,数据 库 级 的 优 
化 能 够 产生 的 优化 效果 十 分 有 限 。 修 改 应 用 ,减少 这 种 全 表 扫 描 才 是 解决 问题 的 根本 之 道 。 

还 有 一 种 情况 是 系统 中 存在 热 链 。 如 果 在 某 个 Hash 链 上 的 多 个 数据 块 都 比较 热 ， 而 且 存 在 
大 量 的 CR Block ( 因为 CR Block 的 DBA 是 相同 的 ， 因 此 某 个 数据 块 的 所 有 CR Block 也 会 在 同 
一 个 Hash 链 里 )， 那 么 这 个 Hash 链 会 变 得 很 热 ， 它 对 应 的 门 锁 就 会 有 严重 的 竞争 。 

如 果 我 们 发 现 STATSPACK 报告 中 的 buffer nowait 技术 指标 是 100% ,并 且 从 buffer busy wait 
小 节 中 看 不 到 很 严重 的 数据 块 的 热 块 冲 突 ， 那 么 cache buffers chains 门 锁 竞 争 很 大 程度 上 可 能 是 
由 于 CR Get 过 多 或 者 热 链 (Hot Chains ) 引起 的 ， 而 不 是 由 于 热 块 引起 的 。 比 如 下 面 的 例子 : 


Child Get Spin & 

Latch Name Num Requests isses Sleeps Sleeps 1->4 

cache buffers chains 634 1,403,566 202,385 1,311 201094/1271/20/0/0 

cache buffers chains 1826 1,317,329 552 45 507/45/0/0/0 

cache buffers chains 1863 1,304,674 565 94 472/92/1/0/0 

cache buffers chains 1613 1,085,545 315 14 301/14/0/0/0 

cache buffers chains 1195 1,047,463 5,948 268 5683/262/310/0 

cache buffers chains 939 1,040,673 261 14 248/12/1/0/0 

cache buffers chains 1314 1,030,316 6,604 40 6567/34/3/0/0 

cache buffers chains 1882 895,423 2,636 109 2531/101/4/0 

上 面 的 数据 是 从 一 个 10 级 的 STATSPACK 报告 中 获取 到 的 ， 这 个 报告 中 包含 了 门 锁 的 子 门 
锁 的 情况 分 析 。 在 一 般 的 生产 环境 中 , 我 们 很 难 采集 到 如 此 详细 的 STATSPACK 报告 ,但 是 在 某 


些 特 殊 的 诊断 情况 下 , 我 们 可 以 视 情况 的 不 同 而 采集 级 别 比 较 高 的 采样 。 在 这 个 报告 中 , 我们 可 
以 看 到 : 


Top 5 Timed Events 


A % Total 
Event Waits Time (s) Ela Ti me 
latch free 183,537 42,065 35.4] 
enqueue 34,562 37,809 31.88 
PX Deq: Txn Recovery Start 6,877 7,864 6.63 
global cache сг request 1,284,391 6,855 5.18 
db file sequential read 1,098,682 6,516 5.55 


在 Top Event "P, latch free 等 待 十 分 严重 ， 平 均 每 次 等 待 的 时 间 也 比较 长 : 
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Avg 
Total Wait Wait Waits 
Event Waits Ti meouts Time (5s) ( ms) [txn 
latch free 183,537 0 42,065 229 5.3 


平均 门 锁 等 待 时 间 为 229 毫秒 ， 这 是 一 个 严重 的 问题 。 我 们 来 检查 一 下 cache buffers chains 


HA, AIRE pct noWait Miss 相当 高 ; 


Get 
Latch Requests 
cache buffers chains 144,311, 


Pct Avg Wait Pct 
Get SI ps Ti me NoWait NoWait 
Miss /Miss (5) Requests Mi ss 
314 0.3 0.1 10735 5,421,525 4.6 


我 们 可 以 看 到 ，634 号 子 门 锁 的 争 用 尤其 严重 ， 其 request, miss 和 sleep 的 数量 均 比 排名 紧 
随 其 后 的 几 个 子 门 锁 要 高 很 多 。 这 就 是 我 们 所 说 的 热 链 。 

如 果 碰 到 了 热 链 ,那么 解决 问题 就 不 是 那么 简单 了 。 有 一 个 可 以 尝试 的 方法 , 就 是 调整 参数 
_db_block_hash_buckets， 或 者 略微 调 大 (或 者 调 小 ) DB Cache 的 大 小 ， 这 样 就 可 以 达到 解散 热 


链 的 目的 。 可 以 选取 一 个 当前 该 参数 值 附近 ( 


咯 大 或 者 略 小 ) 的 素数 , 作为 _db_block_hash_buckets 


值 来 解 开 热 链 。 对 于 Oracle 9 来 说 ， 可 以 设置 db block hash buckets 为 略 大 于 db buffer 数量 的 
2 倍 的 素数 。 每 个 数据 库 版 本 下 ， 这 个 参数 的 调整 方法 是 不 同 的 ， 因 此 在 调整 前 一 定 要 认真 阅读 


相关 的 文档 。 


实际 上 ， 在 碰 到 cache buffers chains 门 锁 竞 争 的 时 候 ， 热 链 存在 的 情况 是 很 多 的 ， 笔 者 就 曾 
经 通过 调整 db block hash, buckets 解决 过 一 个 大 型 系统 的 cache buffers chains 竞争 问题 。 在 调整 
参数 前 ， 平 均 事务 响应 时 间 是 3 秒 多 ，CPU 占用 率 长 时 间 10096, latch free 是 第 一 位 的 EVENT， 
调整 后 ，CPU 占用 率 降 低 到 65%, 平均 事务 响应 时 间 下 降 为 1 秒 左右 。 


调整 前 : 

cache buffers chains 1,528,766,244 0.1 0.4 ###### 65,503,162 23.5 
cache buffers Iru chain 1,667,682 0.6 0.2 182 69,088,014 3.8 
cache buffers chains kcbgtcr: kslbegin excl 0 227,599 414, 454 

cache buffers chains kcbrls: ksl begin 0 199, 620 20,593 

cache buffers chains kcbgtcr: fast path 0 73, 320 77,189 

cache buffers Iru chain kcbzgb: multiple sets пома ####### 2,032 384 

cache buffers Iru chain kcbzgb: posted for free bu 1,900 241 1,393 

cache buffers Iru chain kcbzar: KSLNBEGI № 62,210 177 0 

优化 后 : 

cache buffers chains 1,404,030,764 0.1 0.1 411 62,908,708 0.1 
cache buffers Iru chain 2,659,978 0.6 0.1 12 66,829,453 1.6 
cache buffers chains kcbgtcr: kslbegin excl 0 39,086 41,161 

cache buffers chains kcbgtcr: fast path 0 28,329 25,597 

cache buffers chains kcbrls: ksl begin 0 27, 203 25,948 
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cache buffers Iru chain kcbzgb: multiple sets пома ####### 1,215 111 
cache buffers Iru chain kcbzar: KSLNBEGIN 31,894 109 0 
cache buffers Iru chain kcbzgm 4,500 37 0 
cache buffers Iru chain kcbbiop: Iru scan 15, 376 36 114 


以 上 数据 都 是 在 业务 量 类 似 的 情况 下 ，1 小 时 内 的 采样 。 大 家 可 能 觉得 学 到 了 一 个 优化 热 链 
的 好 方法 ， 其 实数 据 库 的 情况 十 分 复杂 ， 造 成 cache buffers chains 门 锁 争 用 的 三 个 原因 可 能 会 产 
EZL, 实际 的 生产 环境 远 比 我 们 在 理论 上 的 分 析 复 杂 得 多 。 如 果 某 个 数据 块 的 访问 量 很 大 , 也 
就 是 我 们 常 说 的 很 热 ， 而 且 这 个 数据 块 的 CR Block 数量 很 多 ， 那 么 调整 BUCKETS 参数 的 方法 
就 无 法 起 到 很 好 的 作用 了 。 老 白 曾经 和 多 名 资深 的 DBA 讨论 过 db block hash buckets 参数 的 调 
整 问题 ， 他 们 都 有 过 相似 的 经 历 ， 想 通过 调整 这 个 参数 来 改善 cache buffers chains 门 锁 的 争 用 情 
Bí, 不 过 无 一 例外 ,他 们 都 失败 了 。 也 许 是 老 白 的 运气 很 好 ,正好 碰 到 了 一 个 可 以 通过 简单 调整 
参数 来 解决 问题 的 案例 。 

如 果 能 够 确定 问题 是 由 于 热 块 冲突 导致 的 , 那么 一 般 情 况 下 , 我 们 可 以 通过 下 面 的 方法 来 进 
行 优化 。 
а 加 大 表 或 者 索引 的 PCTFREE， 使 每 个 数据 块 中 存放 更 少 的 行 。 
О 减 小 表 空 间 的 Block Size ( 9i 或 者 更 新 的 版 本 )， 使 每 个 数据 块 中 存放 更 少 的 行 。 
О 使 用 Hash 徐 表 ， 打 散 数 据 存放 的 位 置 。 
О 使 用 Hash 分 区 表 ， 使 数据 分 布 更 为 分 散 。 
a 使 用 反 转 键 索 引 ( 针对 索引 )， 减少 类 似 于 主键 热 块 这 样 的 冲突 。 

实际 上 ， 如 果 我 们 发 现 热 链 是 由 于 大 量 的 CR Get 引起 的 ， 那 么 就 需要 认真 分 析 到 底 为 什么 
会 产生 这 么 多 的 CR Get， 这 种 情况 一 般 是 由 大 量 没有 优化 的 SQL 引起 的 ， 因 此 在 必要 时 优化 应 
用 可 能 效果 更 佳 。 


2.4.2 使 用 KEEP POOL 能 改善 CBC 争 用 吗 


使 用 保留 池 (Keep Pool ) 能 否 改善 cache buffers chains 门 锁 争 用 ? 这 个 问题 是 多 年 前 DBA 
界 广 有 争论 的 一 个 话题 。 那 时 候 大 家 对 DB Cache 内 部 结构 的 认识 还 比较 初级 , 都 认为 Keep Pool 
能 够 改善 cache buffers chains 的 争 用 。 

随 着 大 家 对 DB Cache 内 部 结构 的 了 解 ， 以 及 对 Hash 链 和 LRU 链 内 部 结构 的 认识 ， 有 一 些 
DBA 提出 了 一 个 论断 ， 就 是 启用 Keep Pool 仅仅 改变 了 LRU 链 的 结构 ， 对 于 Hash 链 并 无 影响 。 
Keep Pool 启用 后 ,在 LRU 链 结 构 中 ,多 了 一 个 名 为 KEEPPOOLLRU CHAINS 的 链 ， 所 有 Keep 
Pool 的 缓冲 区 都 属于 一 个 DB Cache 中 的 子 池 ， 这 个 池 中 的 Buffer Head 都 链 在 不 同 的 链 上 ， 其 换 
进 换 出 算法 也 和 Default Pool 略 有 不 同 。 不 过 无 论 LRU 链 如 何 变化 ， 都 不 会 影响 到 Hash 链 的 结 
构 。 某 张 表 ， 比 如 T_SMALL 表 ， 无 论 放 在 Default Pool， 还 是 Keep Pool, T: DBA 都 不 会 变化 ， 
DBA 的 散 列 值 也 不 会 变化 , 因此 Hash 链 也 就 不 会 发 生变 化 。 根据 这 个 特点 , 可 以 得 出 一 个 结论 ， 
启用 Keep Pool 无 法 改善 Hash 链 的 性 能 。 
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这 个 观点 似乎 无 懈 可 击 ， 也 是 目前 DBA 界 广 为 接 受 的 观点 ， 不 过 老 白 认为 此 观点 仅仅 是 局 
部 的 真理 。 从 Keep Pool 的 启用 对 Hash 链 的 影响 上 看 ，Keep Pool 并 不 能 改善 cache buffers chains 
争 用 。 但 是 ，Oracle 永远 不 会 是 一 个 判断 题 ， 从 另外 一 个 角度 来 看 ， 由 于 Keep Pool 的 启用 ， 可 
以 将 一 些 访问 十 分 频繁 的 数据 放 人 和 人 其中， 如果 Keep Pool 足够 大 ， 那 么 它 的 命中 率 就 可 以 接近 
100% ,因此 启用 Keep Pool, 可 以 改善 DB Cache 的 命中 率 , 减少 物理 读 。 从 这 个 角度 来 看 ，Keep 
Pool 的 启用 会 减少 SERVER 进程 对 cache buffers chains 的 pin 操作 , 从 而 就 能 够 减少 cache buffers 
chains 的 争 用 。 

从 这 个 例子 我 们 可 以 看 出 ，Oracle 数据 库 是 一 个 十 分 复杂 的 综合 体系 ， 就 像 我 们 地 球 的 生态 
环境 一 样 ， 一 个 变更 可 能 会 引起 连锁 反应 ， 不 是 简单 地 用 公式 就 可 以 描述 的 。 因 此 仅仅 从 问题 的 
表层 去 分 析 是 不 能 客观 反映 出 问题 本 质 的 。 分 析 这 个 问题 ， 不 能 仅仅 从 Hash 链 的 结构 和 cache 
buffers chains 门 锁 本 身 来 考虑 ， 而 应 该 综合 考虑 DB Cache 的 总 体 情 况 ， 这 样 才能 得 到 比较 客观 


事实 上 ， 启 用 Keep Pool 能 否 改善 cache buffers chains 争 用 ， 这 个 问题 还 真 的 不 好 一 概 而 论 ， 
如 果 cache buffers chains 争 用 集中 在 某 些 热 链 上 ， 而 Keep Pool 中 存储 的 对 象 和 这 些 热 链 没有 任 
何 关系 ,那么 启用 Keep Pool 能 够 达到 的 优化 效果 也 会 十 分 有 限 。 


2.4.3 如何 判断 DB Cache £ E. fi 


DB Cache 是 否 够 用 ， 这 是 DBA 经 常 探讨 的 一 个 话题 。 十 多 年 前 ， 内 存 还 是 十 分 昂贵 的 系 
统 资 源 ，CPU 更 是 贵 如 黄金 。 那 时 ， 几 百 MB 的 DB Cache 就 是 很 奢侈 的 配置 了 。 如 果 能 够 保 
证 系统 有 90% 以 上 的 DB Cache 命中 率 ,就 相当 不 错 了 。Oracle 的 官方 文档 也 指出 , “4 DB Cache 
的 命中 率 小 于 90% 的 时 候 ， 就 需要 扩大 DB Cache. 在 很 长 的 时 间 里 , 通过 DB Cache 命中 率 来 
判断 其 是 否 充足 成 为 一 种 标准 。 很 多 文档 都 曾 指 出 ，DB Cache 的 命中 率 要 超过 95%， 否 则 就 
需要 加 大 DB Cache, Oracle 公司 也 将 多 个 HEALTH CHECK 脚本 判断 命中 率 是 否 合理 的 指标 
定 为 90%。 

那么 到 底 DB Cache 的 命中 率 是 多 少 才 算 合 适 呢 ?” 这 可 能 是 很 多 DBA 都 想 知 道 的 ， 不 过 这 
个 问题 怒 怕 无 解 。 因 为 在 目前 的 Oracle 数据 库 版 本 下 ， 通 过 DB Cache 的 命中 率 来 判断 其 是 否 
足够 ， 是 不 科学 的 。 应 用 系统 是 千差万别 的 ， 不 同 的 系统 ， 在 不 同 的 情况 下 ， 对 于 DB Cache 
命中 率 的 要 求 是 不 同 的 。 我 们 分 析 问 题 的 时 候 ， 不 仅仅 要 考虑 某 些 命中 率 的 指标 ， 更 重要 的 是 
要 考虑 在 当前 的 命中 率 前 提 下 ， 系 统 VO 对 系统 性 能 的 整体 影响 ， 以 及 目前 系统 的 CPU. VITE 
的 使 用 情况 。 

以 OWI (Oracle Wait Interface ) 的 观点 和 时 间 模 型 的 观点 来 分 析 性 能 问题 是 目前 Oracle 数据 
库 性 能 分 析 的 主流 方法 ， 也 是 较为 可 取 的 方法 。 虽 然 Oracle 10g 引入 了 ADDM 分 析 等 新 的 概念 ， 
不 过 ADDM 也 是 基于 OWI 和 时 间 模 型 的 一 种 分 析 方 法 ,只 是 ADDM 更 为 智能 而 已 ,在 使 用 OWI 
结合 时 间 模 型 的 方法 时 ， 首 先 我 们 可 以 通过 时 间 模 型 ， 找 到 问题 的 关键 点 ， 那 些 产 生 最 多 等 待 ， 
消耗 最 多 系统 资源 的 地 方 , 就 是 我 们 下 一 步 优 化 的 重点 。 然后 我 们 再 来 看 看 哪些 等 待 事 件 是 最 为 
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严重 的 ， 这 些 等 待 事件 是 否 可 以 优化 。 

具体 应 用 到 分 析 方 面 ，DB Cache 的 命中 率 指标 可 以 作为 我 们 分 析 DB Cache 的 起 点 。 通 过 命 
中 率 指标 我 们 可 以 初步 了 解 DB Cache 的 总 体 情况 ， 一 般 来 说 ， 在 现在 内 存 价格 已 经 十 分 低廉 的 
情况 下 ,一 个 OLTP 系统 的 DB Cache 命中 率 不 应 该 很 低 。 对 于 绝 大 多 数 OLTP 系统 来 说 ,DB Cache 
命中 率 低 于 90% 是 不 可 接受 的 , 甚至 对 于 一 般 的 企业 级 OLTP 系统 来 说 , 低 于 95% 都 是 难以 容忍 
的 。DB Cache 命中 率 低 ， 意 味 着 更 多 的 物理 IO 、 更 多 的 门 锁 使 用 和 较 低 的 效率 。 对 于 一 套 RAC 
系统 , 较 低 的 命中 率 还 意味 着 DB Cache 的 访问 会 产生 更 多 的 实例 间 通 信 消 息 。 因 此 对 于 RAC 系 
统 来 说 ， 往 往 需要 有 更 高 的 DB Cache 命中 率 ， 甚 至 在 有 些 RAC 系统 中 ，98% 的 DB Cache 命中 
率 都 可 能 太 低 了 。 

通过 命中 率 这 一 指标 ， 只 能 让 我 们 对 DB Cache 的 运作 情况 有 一 个 初步 的 了 解 ， 而 不 能 作 
为 我 们 判断 DB Cache 是 否 需 要 调整 的 依据 。 判 断 DB Cache 是 否 配 置 合理 , 要 看 系统 中 是 不 是 
存在 较为 严重 的 VO 等 待 ， 系统 的 IO 是 不 是 过 高 ， 如 果 减 少 UO 的 相关 等 待 ， 系统 的 总 体 性 能 
是 否 能 有 所 提高 。 这 是 一 个 复杂 的 系统 工程 ， 如 果 系 统 中 的 db file sequential read 等 待 十 分 严 
E, 那么 是 不 是 能 够 加 大 DB Cache 来 减少 这 方面 的 等 待 ， 从 而 提高 性 能 呢 ? 目前 系统 的 DB 
Cache 命中 率 达 到 了 98%， 加 大 DB Cache 是 否 能 够 取得 较 好 的 优化 效果 呢 ? 这 些 问题 我 们 需 
要 通过 OWI 分 析 来 找到 答案 。 我 们 可 以 从 等 待 事件 、 门 锁 等 情况 , 分析 DB Cache 的 设置 是 否 
存在 问题 。 

如 果 你 已 经 熟练 掌握 了 ОМІ 分 析 ， 那 么 下 一 步 应 该 学 习 更 高 级 的 分 析 方 法 ， 就 是 一 种 从 系 
统 整体 出 发 的 分 析 方 法 。 它 结合 了 OWI、 时 间 模 型 、 系 统 综合 分 析 ， 从 系统 优化 的 角度 来 分 析 
DB Cache 是 否 需 要 调整 。 做 数据 库 优 化 ， 实 际 上 是 对 系统 的 CPU/MEMVIO 资源 进行 优化 组 合 ， 
通过 对 这 三 者 的 调整 ， 发 挥 系 统 的 最 佳 性 能 。 这 三 者 之 间 的 关系 如 下 : 

о 加 大 DB Cache (MEM )， 可 以 减少 IO， 但 是 会 增加 CPU 的 消耗 。 

О 减少 DB Cache, 会 增加 1O, 减少 CPU 的 消耗 。 

一 名 优秀 的 DBA 应 该 能 够 在 调整 的 时 候 ， 充 分 考虑 系统 资源 的 限制 ， 在 使 任何 一 种 资源 都 
不 出 现 短 板 的 情况 下 ， 提 高 系统 的 总 吞吐 能 力 。 如 果 当 前 的 系统 ,IO 响应 时 间 很 正常 ，IO 性 能 
很 好 ,那么 加 大 DB Cache， 对 系统 整体 性 能 的 提升 是 微乎其微 的 ， 而 对 于 一 个 IO 出 现 了 瓶颈 的 
系统 , 加 大 DB Cache 往往 可 以 获得 较 好 的 性 能 改善 。 另 外 , 对 于 一 个 CPU 已 经 十 分 紧张 的 系统 ， 
盲目 加 大 DB Cache， 可 能 会 导致 更 为 严重 的 性 能 问题 。 因 此 ， 我 们 应 该 对 这 些 因素 有 一 个 综合 
性 的 评估 。 

DBA 应 该 十 分 清楚 自己 的 优化 目的 是 什么 ， 是 提高 整个 系统 的 吞吐 能 力 ， 还 是 提高 某 个 
业务 模块 的 响应 速度 。 在 系统 资源 很 充分 的 时 候 ， 提 高 某 个 模块 的 响应 速度 是 没有 多 少 难度 
的 ,但 是 如 果 在 系统 资源 很 紧张 的 时 候 ， 片 面 地 去 提高 某 个 模块 的 性 能 ， 可 能 会 带 来 很 糟糕 
的 结果 。 

很 多 DBA 总 在 寻找 一 些 方法 或 理论 来 支持 自己 的 工作 。 实 际 上 做 优化 和 练武 术 一 样 ， 练 习 
招 术 只 是 很 初级 的 阶段 ,到 达 一 定 层次 后 ,无 招 胜 有 招 。 如 果 你 进入 了 这 个 境界 ,就 可 以 对 系统 
做 出 任何 操作 ,哪怕 是 一 些 反常 规 的 ,甚至 违背 最 佳 实践 要 求 的 调整 ,但 前 提 是 你 必须 确保 结果 
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是 好 的 。 

举 个 例子 ， 一 个 客户 的 业务 要 对 一 张 超过 ТОВ 的 表 频 繁 地 进行 随机 访问 ， 而 且 随 机 访问 要 
求 的 响应 时 间 十 分 严格 。SQL 是 最 优化 的 了 ， 但 是 响应 速度 仍然 达 不 到 要 求 。 考 虑 到 当时 CPU 
使 用 率 还 较 低 (不 到 50% )， 内 存 也 有 大 量 的 空闲， 我 建议 将 这 张 表 和 相关 索引 放 入 Keep Pool, 
做 了 这 个 操作 后 ， 系 统 响应 时 间 达 到 了 客户 的 要 求 ，CPU 的 使 用 率 上 升 了 10 几 个 百分点 。 按 常 
理 来 说 ， 这 种 操作 是 不 “正确 ”的 ， 也 是 不 建议 使 用 的 , 但 是 在 这 个 场合 ， 此 操作 是 一 个 十 分 有 
效 的 解决 方案 。 

通过 上 面 的 例子 ， 大 家 可 能 也 感觉 到 DB Cache 的 分 析 和 优化 确实 不 是 一 个 简单 的 问题 。 那 
么 我 们 如 何 来 分 析 和 优化 DB Cache 呢 ?” 刚 才 已 经 提 到 了 ， 可 以 先 从 DB Cache 的 命中 率 入 手 ， 
了 解 DB Cache 的 整体 情况 ,然后 再 观察 系统 的 VO 性 能 指标 是 否 合理 ,比如 ,通过 db file sequential 
read 和 db file scattered read 这 两 个 等 待 事件 ， 就 可 以 看 出 数据 库 IO 的 性 能 。 这 两 个 指标 在 通常 
情况 下 都 应 该 是 儿 毫 秒 ， 不 会 超过 10 毫秒 ， 如 果 小 于 4 毫秒 ， 那 么 说 明 目 前 系统 的 VO 性 能 比 
较 良 好 。 接 下 来 ， 检 查 一 下 DB Cache 相关 的 门 锁 争 用 情况 ， 特 别 是 cache buffers Iru chains 门 锁 
的 争 用 情况 。 如 果 该 门 锁 争 用 较为 严重 ， 那 么 说 明 DB Cache 存在 不 足 。 下 面 我 们 通过 
STATSPACK/AWR 报告 的 DB Cache 相关 章节 来 进一步 分 析 : 


Buffer Pool Statistics for DB: BILL Instance: XXXX Snaps: 262 -263 
-> Standard block size Pools D: default, K: keep, R: recycle 
-> Default Pools for other block sizes: 2k, 4k, 8k, 16k, 32k 


Free Wite Buffer 


Number of Cache Buffer Physical Physical Buffer Complete Busy 
P Buffers Hit % Gets Reads Writes Waits Waits Waits 
D 126,592 297.3 11,269,283 2,100,417 92,173 0 0 87,036 
K 63,296 93.5 155,457 10,060 152 0 0 0 


在 这 里 , 要 重点 关注 每 个 缓冲 池 的 命中 率 , 因为 在 前 面 我 们 看 到 的 是 DB Cache 的 总 命中 率 ， 
而 在 这 里 可 以 看 到 所 有 CACHE 的 命中 率 。 上 面 的 例子 中 ， 系 统 有 DEFAULT 和 KEEP 两 个 缓冲 
池 。Keep Pool 的 命中 率 只 有 93.5%, 这 是 一 个 偏 低 的 值 ,在 一 个 运行 较 长 时 间 的 系统 中 , Keep Pool 
的 命中 率 应 该 接近 100%， 否 则 就 说 明 Keep Pool 可 能 设置 不 足 。 除 了 Keep Pool 的 命中 率 外 ， 还 
需要 关注 Free Buffer Waits 和 Write Complete Waits 的 指标 。 如 果 这 两 个 指标 不 为 0， 那 么 就 需要 
我 们 重视 了 。 这 两 个 统计 指标 在 前 面 章节 介绍 DB Cache 内 部 算法 的 时 候 都 已 经 介绍 过 了 ， 它们 
都 是 前 台 进 程 查找 free buffer 时 碰 到 的 等 待 ， 不 为 零 说 明 前 台 进 程 出 现 过 等 待 Free Buffer 或 者 等 
f$ DBWR 写 脏 块 结束 的 情况 。 这 两 项 统计 数据 从 另外 一 个 方面 说 明了 DB Cache 存在 严重 不 足 。 
这 些 指标 比 命中 率 更 为 关键 。 

随 着 硬件 价格 大 幅 下 降 , DB Cache 的 调整 难度 也 有 所 下 降 , 只 要 系统 中 存在 较为 充足 的 CPU 
和 内 存 资 源 ， 那 么 把 DB Cache 设置 得 偏 大 一 些 ， 是 没有 多 少 风险 的 。 因 此 我 们 可 以 尽 可 能 地 配 
置 充足 的 DB Cache。 

不 过 在 一 些 存在 资源 瓶颈 的 系统 中 ， 调 整 DB Cache 仍然 有 一 定 难度 。 接 下 来 介绍 的 这 个 案 
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例 就 很 有 代表 性 。 

一 个 客户 的 系统 ， 每 天 业务 高 峰 期 时 CPU 使 用 率 都 高 达 80% 左 右 ， 最 近 一 段 时 间 ， 甚 至 达 
到 100%， 如 果 发 现 得 早 ， 尽 快 杀 掉 一 些 进程 ， 才 能 够 确保 系统 安全 ; 如果 发 现 得 晚 ， 可 能 导致 
系统 HANG 死 。 在 CPU 高 位 运行 的 时 候 ， 一 般 来 说 是 不 建议 加 大 DB Cache 的 。 不 过 经 过 分 析 ， 
我 们 发 现在 这 个 系统 中 有 一 个 查询 语句 ， 正 常情 况 下 , 在 V$SESSION 中 看 到 的 这 条 语句 的 数量 
大 概 有 50 条 ， 出 现 问题 的 时 候 ， 这 条 语句 的 数量 往往 会 超过 100, 甚至 接近 200。 这 条 语句 在 正 
常 时 和 非 正常 时 的 CPU 消耗 是 十 分 接近 的 ， 而 总 体 执行 时 间 却 相差 很 大 。 这 就 说 明 在 该 语句 执 
行 过 程 中 ,产生 了 更 多 的 等 待 ， 这 些 等 待 主要 集中 在 db file sequential read 和 一 些 与 DB Cache fH 
关 的 门 锁 等 待 方面 。 经 过 进一步 分 析 , 我 们 发 现 这 条 语句 访问 的 分 区 表 的 最 新 分 区 存储 在 一 个 新 
建 的 磁盘 组 上 ， 这 个 磁盘 组 是 RAID 5 的 ， 使 用 了 较 大 的 磁盘 ， 不 过 磁盘 的 数量 较 少 ， 因 此 总 体 
VO 能 力 远 低 于 以 前 的 磁盘 组 。 将 这 个 分 区 迁 出 目前 的 磁盘 组 是 较为 彻底 的 解决 方法 ， 不 过 由 于 
这 是 一 个 7x 24 的 核心 系统 , 不 可 能 给 我 们 留 出 足够 的 迁移 时 间 , 我 们 必须 从 另外 的 角度 来 考虑 
解决 方案 。 这 个 时 候 ， 就 需要 道 向 思维 了 。 系 统 的 CPU 为 什么 会 突然 升 高 ? 那 是 由 于 磁盘 IO 性 
能 不 足 ， 导 致 这 个 查询 的 时 间 比 正常 情况 慢 了 5 ~ 10 倍 , 由 于 应 用 服务 器 端 没 有 对 这 类 查询 进行 
排队 ， 该 模块 性 能 变 慢 ,使 得 更 多 的 查询 请 求 被 积压 ， 同 时 在 系统 中 处 理 的 该 查询 数量 增加 ,并 
发 访问 量 增 加 了 数 倍 ， 再 加 上 门 锁 争 用 使 CPU 资源 消耗 量 不 断 提高 ， 最 终 导致 系统 过 载 。 分 析 
清楚 了 这 一 点 , 下 一 步 就 要 考虑 ， 如 果 我 们 加 大 DB Cache 会 怎么 样 呢 ? 会 不 会 导致 CPU 资源 消 
耗 进 一 步 恶化 呢 ? 加 大 DB Cache Ja, WO 会 有 所 减少 , 这 个 SQL 的 VO 等 待 会 降低 , cache buffers 
chains 门 锁 争 用 也 会 有 所 降低 ， 那 么 这 个 SQL 的 执行 时 间 就 会 缩短 。 如 果 SQL 的 执行 时 间 缩 短 
到 一 定 程度 ， 这 个 查询 就 不 会 产生 长 时 间 的 积压 。 如 果 不 产 生长 时 间 的 查询 积压 ， 就 不 会 达到 
CPU 资源 的 临界 点 ， 那 么 系统 故障 也 就 能 避免 了 。 因 此 我 们 决定 加 大 DB Cache， 操 作 完 成 后 ， 
VO 性 能 确实 有 所 改善 ， 这 个 SQL 的 执行 时 间 也 缩短 了 ， 虽然 偶尔 也 会 产生 该 查询 的 积压 , 但 是 
很 快 就 会 逐渐 减少 。 

上 面 的 案例 通过 一 个 看 似 会 恶化 CPU 资源 的 操作 ， 居 然 解决 了 CPU 的 问题 。 这 是 什么 道 
理 呢 ? 实际 上 , 这 个 问题 并 不 是 真正 的 CPU 资源 出 现 了 瓶颈 , 最 终 系统 月 演 的 时 候 确实 是 CPU 
资源 出 现 了 不 足 ， 但 是 资源 不 足 是 由 于 应 用 架构 不 合理 导致 了 大 量 查询 积压 ， 积 压 到 一 定 程度 
才 导 致 CPU 资源 不 足 。 在 这 种 情况 下 解决 问题 不 能 拘泥 于 陈规 ， 只 要 想 办 法 不 让 查询 积压 ， 那 
Z CPU 资源 不 足 的 现象 就 不 会 出 现 ， 这 个 问题 也 就 解决 了 ， 所 以 我 们 果断 地 提出 了 加 大 DB 
Cache 的 方案 。 

熟悉 的 人 总 是 说 我 有 很 多 奇 思 妙 想 , 做 事 完全 不 受 条 条 框框 的 限制 。 以 我 这 些 年 做 性 能 优化 
的 经 验 , 操作 层面 上 的 内 容 是 很 简单 的 , 但 是 要 达到 无 招 胜 有 招 的 境界 ,就 必须 对 Oracle 的 基本 
原理 十 分 熟悉 ， 要 明白 每 个 操作 可 能 产生 的 后 果 ， 并 且 从 中 排除 主要 风险 。 在 调整 DB Cache 的 
时 候 也 是 这 样 ， 每 个 操作 之 前 ， 必 须 应 用 DB Cache 的 基本 原理 ， 分 析 可 能 会 带 来 的 影响 。 有 一 次 
我 们 为 客户 做 优化 , 由 我 们 的 一 名 资深 工程 师 实 施 完成 , 通过 优化 , 系统 响应 时 间 缩 短 为 原来 的 十 
分 之 一 ，CPU 使 用 率 从 10096 FEN 50% 左 右 。 后 来 一 个 Oracle 的 朋友 问 我 是 怎么 做 到 的 ， 我 说 
其 实 很 简单 ， 做 表 分 析 ， 要 求 客 户 将 SQL 中 的 提示 全 部 去 掉 。 因 为 这 个 项 目 Oracle 也 介入 过 , 但 
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是 没有 找到 很 好 的 解决 方案 , 他 感慨 道 ,这 些 操作 很 容易 ,但 是 敢于 完成 这 个 操作 的 人 , TER 
正 的 高 手 。 确 实 是 这 样 的 ,真正 的 高 手 并 不 是 拥有 一 些 所 谓 独门 秘笈 的 人 ， 而 是 能 够 做 出 合理 判 
Wr A. 


2.4.4 DB Cache 优化 要 点 


通过 前 面 章节 关于 DB Cache 的 一 些 基本 概念 的 介绍 ,大 家 可 能 已 经 了 解 了 什么 是 DB Cache, 
以 及 DB Cache 是 如 何 工 作 的 。 可 能 有 些 读者 已 经 能 够 悟 出 调整 DB Cache 的 一 些 思路 了 ， 不 过 
这 方面 经 验 不 是 很 丰富 的 读者 ， 可 能 还 是 存在 一 定 的 疑惑 。 经 常 有 朋友 问 我 ， 该 如 何 设置 DB 
Cache 呢 ?”95% 的 命中 率 是 否 说 明 DB Cache 是 充足 的 ? 

实际 上 DB Cache 的 本 质 就 是 一 个 缓冲 区 ， 可 以 让 数据 文件 中 的 数据 尽 可 能 一 次 读 取 多 次 持 
用 。 因 此 DB Cache 的 优化 并 无 一 个 明确 的 命中 率 指标 ， 而 需要 根据 实际 情况 来 具体 分 析 。 对 于 
一 个 存储 性 能 十 分 优秀 的 系统 来 说 , 只 要 存储 的 能 力 是 充足 的 , 那么 哪怕 DB Cache 设置 得 偏 小 ， 
命中 率 偏 低 ， 系统 的 总 体 性 能 也 还 可 以 忍受 , 客户 也 不 一 定 能 够 发 现 系 统 性 能 存在 问题 。 而 对 于 
— VO 性 能 不 佳 的 系统 ,DB Cache 的 命中 率 稍微 下 降 一 点 ,可 能 就 会 引起 十 分 严重 的 性 能 问题 ， 
客户 端 就 能 够 很 明确 地 感受 到 性 能 下 降 。 因 此 ，DB Cache 的 优化 和 系统 整体 资源 的 情况 也 是 息 
息 相 关 的 ， 不 仅仅 取决 于 数据 库 的 性 能 指标 。 

前 面 的 章节 已 经 介绍 了 很 多 DB Cache 的 内 部 原理 ， 可 能 很 多 读者 在 阅读 这 部 分 内 容 时 会 感 
觉 头 昏 脑 胀 ， 异 昏 欲 睡 。 不 过 这 也 没关系 ， 因 为 对 于 绝 大 多 数 DBA 来 说 ， 不 需要 了 解 特别 多 的 
DB Cache 内 部 原理 的 细节 。 但 是 DB Cache 的 性 能 是 对 Oracle 数据 库 性 能 影响 最 大 的 ， 因 此 如 何 
管理 好 DB Cache 是 十 分 关键 的 。 我 们 对 于 DB Cache 的 理解 可 以 比较 粗浅 ， 但 是 对 于 本 节 介 绍 
的 DB Cache 的 优化 要 点 ， 需 要 认真 研究 ， 并 且 一 定 要 真正 地 掌握 。 

对 于 DB Cache 的 优化 ， 老 白 根 据 这 些 年 的 经 验 ， 总 结 了 以 下 的 几 个 总 体 建议 。 

О 在 内 存 、CPU 资源 都 充足 的 情况 下 ,尽量 将 DB Cache 配置 得 大 一 些 , 防止 在 业务 峰值 时 

DB Cache 不 足 。 

а 尽量 使 用 多 缓冲 ， 使 用 KEEP POOL, NK POOL 之 类 的 缓冲 池 ， 虽 然 使 用 多 缓冲 会 
加 大 DBA 的 工作 量 ， 但 还 是 值得 的 。 使 用 了 多 缓冲 ， 就 要 考虑 哪些 对 象 放 人 哪些 组 
冲 (NK 缓冲 涉及 不 同 Block Size 的 表 空 间 ， 放 人 该 表 空 间 的 对 象 会 被 自动 放 和 人 对 应 
的 NK 组 冲 )。 

Па 无 论 如 何 配置 ， 千 万 别 让 操作 系统 产生 换 页 。 对 于 UNIX 系统 ， 还 要 注意 调整 操作 系统 
的 虚拟 内 存 参数 ， 比 如 AIX 系统 的 MAXPERM9% 人 参数 ， 避 免 FILE BUFFER/CACHE 占用 
大 量 的 内 存 。 虽 然 AIX 可 以 通过 参数 调整 ， 在 物理 内 存 不 足 时 ， 尽 可 能 将 非 计 算 内 存 换 
出 ， 而 不 会 换 出 计算 内 存 ， 但 是 如 果 系 统 的 物理 内 存 空闲 总 是 十 分 小 (比如 说 只 有 几 百 
兆 )， 罕 然 出 现 几 个 大 查询 将 物理 内 存 耗 尽 了 ， 那 么 操作 系统 就 会 产生 换 页 。 首 先 要 将 部 
分 非 计算 内 存 换 到 交换 区 ， 然 后 释放 内 存 给 相关 的 会 话 使 用 。 这 时 ， 换 页 会 消耗 大 量 的 
CPU 资源 ， 从 而 导致 某 些 业务 模块 变 慢 。 目 前 的 绝 大 多 数 应 用 系统 都 没有 设计 应 用 访问 
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队列 的 机 制 ， 无 法 主动 平滑 系统 峰值 。 当 某 个 常用 查询 模块 变 慢 时 ， 就 会 有 更 多 的 查询 
请 求 涌 入 ， 从 而 导致 会 话 数量 猛 增 ， 产生 更 多 的 物理 内 存 需求 ， 需 要 操作 系统 换 出 更 多 
的 非 计算 内 存 ， 以 满足 当前 的 物理 内 存 需求 。 这 样 可 能 导致 换 页 操作 持续 几 分 钟 甚至 几 


十 分 钟 。 在 这 个 时 间 段 内 ， 就 可 能 出 现 严重 的 性 能 问题 ， 对 于 КАС 系统 ， 其 至 可 外 
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脑 裂 的 危险 ， 导 致 某 个 节点 被 迫 重启 。AIX 系统 的 MAXPERM% 默 认 值 为 80%, HP-UX 
默认 的 文件 缓冲 可 使 用 物理 内 存 的 最 大 比例 是 50% ， 这 些 设置 ， 对 于 数据 库 服务 器 来 说 
都 太 高 了 ( 相对 来 说 SUN 的 操作 系统 比较 合理 ， 类 似 的 参数 默认 值 是 12% )。 无论 是 否 
使 用 裸 设备 ， 操 作 系 统 的 文件 缓冲 区 对 于 Oracle 来 说 都 是 没有 多 大 作用 的 ， 即 便 是 纯粹 


的 RDBMS SERVER，MAXPERM% 设 置 为 10 也 已 经 够 高 了 。 


加 大 DB Cache 可 以 减轻 IO 的 负载 ， 提 高 VO 的 总 体 响应 速度 。 


O 如 果 VO 存在 问题 , 除了 修改 SQL、 做 负载 均衡 外 ,最 可 能 的 解决 方案 是 调整 DB Cache, 


о 加 大 DB Cache， 可 以 减轻 IO 的 负载 ,但 同时 可 能 会 消耗 更 多 的 CPU 资源 。 前 面 提 到 ， 


绝 大 多 数 应 用 系统 都 没有 设计 应 用 缓冲 队列 ,因此 缺乏 平缓 峰值 的 功能 。 如 果 加 大 了 DB 
Cache, 减轻 了 VO 的 负载 ， 整 个 系统 的 处 理 能 力 就 会 得 到 提升 ， 那 么 单位 时 间 内 处 理 的 


事务 数量 也 会 增加 。 原 本 在 应 用 服务 器 端 排队 的 访问 请 求 会 更 快 地 将 数据 库 操 作 力 


1 载 到 


数据 库 服务 器 上 , 因此 数据 库 服务 器 的 CPU 消耗 可 能 会 有 所 提升 。 在 CPU 资源 已 经 十 分 


=> 


紧张 的 情况 下 ， 大 幅度 加 大 DB Cache 就 是 一 件 要 十 分 慎重 的 事 ' 


月 o 


а 如 果 出 现 IO 问题 , 除了 看 DB Cache 的 命中 率 外 ， 最 应 该 看 的 是 STATSPACK 里 的 FILE 


VO, LATCH 这 些 节 ， 当 然 如 果 有 TOP OBJECT 的 话 ， 可 以 获取 更 多 的 辅助 信息 。 
LATCH 这 节 ， 一 定 要 观察 Latch Miss Sources， 这 里 会 体现 更 多 的 细节 。 


对 于 


a 使 用 10g 的 朋友 ， 不 要 育 目 相信 Oracle 的 自动 共享 内 存 管理 ( ASMM )， 在 使 用 ASMM 
的 同时 ， 也 要 防止 共享 内 存 出 现 严重 的 抖动 。 如 果 共 享 内 存 中 的 DB Cache 和 SHARED 


POOL 总 是 在 不 停 地 调整 , 那么 可 能 会 对 系统 的 性 能 产生 更 为 严重 的 负面 影响 。 最 为 显著 
的 特点 就 是 ，Cursor 相关 的 等 待 事件 会 大 量 出 现 。 类 似 “cursor:pin S wait on X” 这 样 的 


等 待 可 能 会 让 系统 出 现 严 重 的 性 能 问题 ， 甚 至 短暂 地 挂 起。 


其 实 上 面 的 几 点 ,概括 起 来 就 是 如 果 物 理 内 存 足够 ,而且 CPU 资源 充足 , 那么 尽 可 能 将 DB 
Cache 设置 得 大 一 些 ， 加 大 DB Cache 一 般 不 会 有 太 大 的 副作用 。 如 果 你 能 把 整个 数据 库 都 放 到 


DB Cache 中 ， 那 么 一 般 来 说 DB Cache 也 不 会 出 现 什么 性 能 问题 。 而 较 小 的 DB Cache 带 来 的 性 


能 问题 往往 会 比较 严重 。 


对 于 CPU 资源 十 分 紧张 的 系统 ， 就 不 建议 随意 加 大 DB Cache 了 。 前 几 天 碰 到 一 个 客户 , 他 


们 的 系统 刚刚 上 线 不 到 三 个 月 ， 就 出 现 了 CPU 资源 紧张 的 现象 ,每 天 的 业务 高 峰 期 CPU 使 用 率 


都 达到 了 90% 左 右 。 后 来 他 们 将 SGA_TARGET 调 小 后 ,CPU 资源 的 使 用 率 下 降 了 10%, E 


RAN 


减 小 了 SGA_TARGET， 不 过 从 AWR 报告 上 看 ，DB Cache 的 命中 率 也 在 97% ~ 98% 之 间 ， 


仍然 


处 于 合理 的 范围 内 。db file sequential read 的 平均 响应 时 间 在 8 毫秒 左右 ， 也 基本 上 能 够 接受 。 这 
样 的 调整 ， 虽 然 降 低 了 总 体 的 系统 性 能 ,但 是 主要 核心 模块 的 响应 时 间 还 在 合理 的 范围 内 。CPU 
使 用 率 的 下 降 ， 降 低 了 突 发 事件 导致 CPU 出 现 严重 瓶颈 的 机 会 。 这 种 调整 从 整体 上 来 说 还 是 成 
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功 的 。 

如 果 减 小 SGA_TARGET 导致 了 严重 的 SGA RESIZE, 或 者 cache buffers chains 门 锁 的 争 用 
十 分 严重 了 ， 那 么 这 个 调整 就 是 不 合理 的 ， 有 可 能 会 引起 更 为 严重 的 性 能 问题 。 

因此 调整 DB Cache 的 时 候 ， 特 别 是 减 小 DB Cache 的 时 候 ， 需 要 РВА 有 充足 的 分 析 ， 否 则 
很 容易 引起 负面 的 影响 。 这 时 ，AWR 报告 中 的 Buffer Pool Advisory 小 节 的 内 容 就 是 一 个 很 好 的 
参考 。 我 们 可 以 根据 系统 的 评估 , 判断 减少 DB Cache 后 可 能 带 来 的 ТО 的 增加 情况 ， 从 而 预测 减 
少 DB Cache 后 系统 是 否 会 产生 严重 的 性 能 问题 。 


共享 池 是 Oracle 数据 库 中 一 个 十 分 重要 的 缓冲 池 。 实 际 上 我 们 在 SQL*Plus 中 使 用 SHOW 
SGA 命令 就 可 以 看 到 SGA 的 几 个 主要 组 成 部 分 : 
SQL> show sga 


Total System Global Area 1048576000 bytes 


Fixed Size 1271444 bytes 
Variable Size 511707500 bytes 
Database Buffers 532676608 bytes 
Redo Buffers 2920448 bytes 
SQL» 


Oracle 的 SGA 包含 固定 数据 结构 部 分 ( Fixed Size ), 数据 块 缓冲 区 ( Database Buffers ), Redo 
Log 缓冲 区 (Redo Buffers )、 共 享 池 (包含 在 Variale Size 中 ) 等 儿 大 部 分 。 固 定数 据 结 构 部 分 包 
含 了 数据 库 的 一 些 固定 的 数据 结构 ， 包 括 所 有 其 他 共享 内 存 结构 的 地 址 和 指针 等 。 

共享 池 是 SGA 中 的 一 个 组 件 ， 传 统 上 我 们 认为 共享 池 包含 字典 缓冲 (row cache) 和 库 缓冲 
(library cache ) 两 个 部 分 ,实际 上 共享 池 的 结构 要 复杂 得 多 ， 共 享 池 中 还 包含 数据 库 的 一 些 十 分 
重要 的 数据 结构 ， 比 如 资源 、 锁 等 。 通 过 下 面 的 SQL， 我 们 可 以 了 解 到 共享 池 中 包含 哪些 组 件 。 

SELECT pool, name, bytes FROM v$sgastat where pool='shared pool'; 
顾名思义 ,共享 池 是 为 了 让 大 家 共享 数据 而 设置 的 缓冲 池 。 共 享 池 中 有 很 多 组 件 , 而 且 共 享 
池 也 是 很 多 会 话 为 自己 执行 SQL 分 配 共享 内 存 的 缓冲 池 ， 这 些 在 共享 池 中 分 配 的 内 存在 会 话 之 
间 使 用 十 分 频繁 ， 应 实现 一 次 分 配 多 次 使 用 ， 并 且 能 够 被 实例 中 的 所 有 会 话 共 享 。DB Cache 可 
以 根据 数据 块 大 小 很 规则 地 进行 均匀 分 配 ， 因 此 不 会 出 现 碎 片 问题 ， 而 且 DB Cache 的 分 配 和 归 
还 也 相对 简单 。 和 DB Cache 不 同 ， 由 于 各 个 会 话 在 共享 池 中 分 配 空 间 的 时 候 ， 所 需要 的 空间 差 
异 很 大 ,有 的 只 有 几 十 字 节 ,而 有 的 需要 几 百 千 字 节 甚 至 几 兆 字 节 ,因此 共享 池 的 分 配 和 归还 算 
法 十 分 复杂 。 为 了 确保 共享 池 中 共享 数据 的 访问 性 能 , 共享 池 的 每 次 内 存 分 配 都 必须 是 连续 的 内 
存 空 间 。 由 于 这 个 特点 ， 经 过 一 段 时 间 的 运行 ,共享 池 中 或 多 或 少 都 会 出 现 一 些 碎 片 ， 这 些 碎片 
分 布 在 一 些 连续 分 配 的 空间 之 间 。 

共享 池 中 分 配 的 内 存 空 间 , 有 些 是 永久 使 用 ,不 会 释放 的 ,这些 内 存 空 间 被 标识 为 permanent， 
这 些 结构 大 多 数 是 在 实例 启动 时 分 配 的 , 也 有 一 些 是 在 系统 运行 过 程 中 临时 分 配 的 , 不 过 这 些 内 
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存 的 特点 是 只 分 配 ， 在 实例 关闭 前 基本 上 不 会 释放 。 最 为 典型 的 永久 性 内 存 包括 进程 信息 数据 、 
会 话 信息 数据 和 一 些 特殊 用 途 的 内 存 段 。 进 程 信息 和 会 话 信息 所 使 用 的 内 存 是 根据 参数 processes 
和 sessions 在 实例 启动 时 一 次 性 分 配 的 ,一 旦 分 配 就 不 会 变动 ， 也 不 会 动态 扩展 。 因 此 加 大 
processes BA, 必须 重启 实例 才能 够 起 作用 。 另 外 一 些 特殊 用 途 的 内 存 数 组 也 是 根据 参数 在 实例 
启动 时 进行 分 配 的 , 但 是 在 数据 库 实 例 运行 过 程 中 , 如 果 这 些 数组 出 现 不 足 , 是 可 以 动态 扩展 的 。 
这 些 动态 扩展 的 内 存 也 是 permanent 的 ， 一 旦 分 配 就 不 会 释放 。 这 些 数组 包括 enqueues(lock). 
enqueue resource, transactions, transaction branches 等 ， 对 于 RAC 系统 ， 还 有 gcs resource, ges 
resource 等 。 这 些 动态 扩展 的 内 存 结构 ， 如 果 经 常 发 生 扩展 ， 将 会 在 共享 池 的 连续 内 存 空间 中 ， 
产生 大 量 的 不 可 释放 的 小 碎片 ， 从 而 导致 共享 池 碎 片 化 。 

一 个 最 为 典型 的 案例 就 是 在 Oracle 9i RAC 中 经 常 由 于 GES RESOURCE 数据 结构 的 扩展 导 
致 共享 池 碎 片 问题 。GES RESOURCE 资源 在 数据 库 启 动 时 从 共享 池 中 分 配 内 存 ， 随 着 RAC 
GLOBAL ENQUEUE 的 使 用 量 的 增长 WR GES RESOURCE 出 现 了 不 足 , 那么 这 个 数据 结构 会 
自动 扩展 , 而 且 这 些 扩展 的 数据 是 permanent 的 ， 只 分 配 不 释放 。 TE 9i RAC 数据 库 中 , 每 个 GES 
RESOURCE 分 配 几 十 字 节 ， 而 且 每 次 只 扩展 一 个 GESRESOURCE。 随 着 GES RESOURCE 不 断 
增长 ， 共 享 池 碎 片 化 趋势 就 会 越 来 越 严 重 ， 最 终 甚 至 完全 碎片 化 。 这 时 ， 即 使 我 们 通过 ALTER 
SYSTEM FLUSH SHARED_POOL 来 整理 共享 地， 效果 也 不 大 。 随 着 共享 池 碎 片 化 加 剧 ， 这 个 系 
统 最 终 可 能 由 于 ORA-4031 而 宕 机 。 解 决 这 个 问题 可 以 从 两 个 方面 去 考虑 ， 第 一 个 方面 是 加 大 
GES RESOURCE 的 初始 分 配 值 ， 使 之 不 产生 动态 分 配 ; 第 二 个 方面 是 在 扩展 GES RESOURCE 
的 时 候 , 每 次 扩展 一 组 , 而 不 是 一 个 , 从 而 减少 扩展 的 次 数 。 我 们 可 以 通过 设置 足够 大 的 _Im_locks 
和 _lm_ress 参数 来 解决 第 一 个 问题 ， 这 样 数据 库 启动 时 就 会 分 配 足 够 多 的 GES RESOURCE, XJ 
于 第 二 个 问题 ，10.2 版 已 经 对 GES RESOURCE 的 扩展 方法 进行 了 修改 ,不 再 是 一 次 扩展 一 个 资 
源 ， 而 是 扩展 一 组 。 因 此 ， 这 个 故障 在 Oracle 10g R2 数据 库 中 很 少 会 出 现 ， 但 不 排除 在 一 些 极 
端的 情况 下 仍 会 出 现 ， 这 时 ， 就 需要 考虑 设置 那 两 个 隐 含 参数 了 。 

共享 池 中 还 有 一 些 分 配 的 内 存 是 可 释放 的 ， 这 些 内 存 被 标志 为 freeable 或 者 recreateable。 
freeable 的 内 存 是 可 以 直接 释放 的 ， 而 recreateable 的 内 存在 unpin 后 也 是 可 以 释放 的 。 因 此 ， 它 
们 都 是 可 以 重用 的 内 存 。 

共享 池 的 内 存 是 通过 Oracle 通用 内 存 管理 (generic Oracle memory manager ) 来 进行 管理 的 ， 
这 个 管理 机 制 也 就 是 我 们 常 说 的 KGH heap Manager, TE KGH heap Manager 机 制 下 ， 所 有 共享 池 
的 free 内 存 都 被 挂 在 称 为 freelists 的 空闲 链表 上 ， 这 个 空闲 列表 是 按照 bucket 的 机 制 建立 的 ， 根 
据 空 闪 内存 片段 的 大 小 ， 挂 在 不 同 的 bucket Eo L Oracle 9; 为 例 ， 共 享 池 的 freelists 包含 256 个 
bucket， 每 个 bucket 上 链接 了 不 同 大 小 的 空闲 内存 块 。 具 体 情况 如 下 : 


о 小 于 812B 的 bucket 是 以 4B 为 步 长 增长 的 ， 如 16B，20B，24B,，…… , 812B; 
О 超过 812B 的 bucket 是 以 64B 为 步 长 增长 的 ， 如 876B, 940B, === , 4012B; 
Па 超过 4012B 的 bucket 是 以 4096 的 倍数 倍增 的 , 如 4108, 8204, 16396, 32780, 65548, 


当 某 个 会 话 需要 从 共享 池 中 分 配 空间 的 时 候 , 会 根据 自己 分 配 的 大 小 找到 茶 个 bucket， 然 后 
找到 一 个 空闲 的 内 存 ,， 从 中 分 配 。 分 配 产生 的 剩余 内 存 , 会 被 挂 到 相应 的 bucket E, 供 其 他 会 话 
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分 配 使 用 。 而 被 释放 的 内 存 叉 会 被 挂 到 Freelists 上 ， 为 了 确保 共享 池 的 内 存 运 行 一 段 时 间 后 不 会 
碎片 化 ,被 释放 的 内 存 会 自动 进行 合并 ， 如 果 释 放 的 两 个 内 存 片 段 是 相 邻 的 ，Oracle 会 将 它们 自 
动 合并 为 一 个 大 内 存 。 

共享 池 的 大 小 通过 参数 shared pool size 来 定义 。 在 Oracle 共享 内 存 自 动 管理 或 者 Oracle A 
动 内 存 管 理 模式 下 ， 可 以 不 设置 shared pool size 参数 ， 由 数据 库 自 动 来 根据 系统 负载 分 配 共享 
池内 存 。 如 果 这 时 我 们 设置 了 shared pool size 参数 ， 那 么 这 个 参数 会 作为 共享 池 的 初始 大 小 和 
最 小 值 。 无 论 内 存 如 何 自动 调整 ， 共 享 池 的 大 小 都 不 能 小 于 这 个 值 。 

共享 池 及 其 内 存 管理 算法 都 十 分 复杂 , 如 何 从 这 些 纷繁 的 算法 中 掌握 最 为 基本 的 方法 ,从 而 
帮助 我 们 分 析 问 题解 决 问题 呢 ? 接 下 来 的 这 一 节 中 , 老 白 将 会 和 大 家 一 起 来 理解 共享 池 中 的 那些 
著名 的 算法 ， 并 通过 对 这 些 知 识 的 理解 ， 学 会 分 析 共 享 池 的 问题 。 


3.1 共享 池 堆 的 内 部 结构 


要 想 深 入 分 析 共 享 池 内 存 的 管理 , 必须 要 知道 Oracle 的 内 存 空间 分 配 是 采用 堆 管 理 ( HEAP ) 
的 模式 ， 堆 管理 的 基础 就 是 KGH。 因 此 本 节 将 会 介绍 一 些 稍微 深入 一 点 的 Oracle KGH 的 基本 原 
理 。 这 部 分 内 容 可 能 有 些 枯 燥 ， 甚 至 对 于 某 些 人 来 说 可 能 有 点 难 , 不 过 没关系 ， 如 果 你 真 的 没有 
兴趣 看 下 去 , 可 以 直接 跳 过 本 节 , 这 样 恐 伯 你 会 在 理解 共享 池内 部 空间 管理 的 一 些 深 入 算法 时 产 
生 一 些 偏 差 ， 而 不 会 导致 你 无 法 理解 共享 池 的 基本 算法 。 可 以 说 ,本 节 是 专门 为 希望 了 解 Oracle 
内 存 管 理 细节 的 资深 入 士 准备 的 ， 如果 你 暂时 无 法 理解 这 些 细节 ,就 完全 可 以 忽略 。 男 外 本 节 涉 
及 的 内 容 对 于 没有 开发 经 验 的 DBA 来 说 ， 可 能 会 有 些 困 难 。 

Oracle 中 最 常见 的 内 存 堆 包括 SGA HEAP, PGA HEAP， 男 外 ,我们 最 常见 的 表 也 是 HEAP 
TABLE， 其 空间 管理 的 基本 概念 都 是 使 用 KGH。 

Oracle 的 各 种 内 存 组 织 都 是 堆 形 式 的 ,每 个 堆 包含 一 个 扒 句 柄 和 一 系列 的 内 存 扩展 ， 每 个 扩 
展 又 包含 了 一 系列 连续 的 Chunk。 内 存 申请 者 通过 在 堆 上 申请 空间 的 模式 来 获得 内 存 。 我们 常见 
的 SGA、PGA 都 是 以 堆 的 形式 管理 的 ,在 堆 上 分 配 空间 (Chunk ) 时 , 根据 ALLOCATION CLASS 
的 不 同 ， 其 管理 模式 也 不 同 。Chunk 是 一 个 连续 的 内 存 片段 ， 这 些 内 存 片 段 可 以 分 为 以 下 几 类 。 

口 PERMANENT: 这 类 Chunk 是 通过 KGHACPERM 标志 来 分 配 的 ， 一旦 被 分 配 ， 在 整个 


堆 的 生命 周期 里 就 不 能 被 解锁 和 释放 。 一 些 常 用 的 、 容 易 产生 内 存 碎片 的 Chunk 一 般 采 
用 PERMANENT 方式 分 配 。 

口 FREEABLE: 这 类 Chunk 是 通过 KGHACFREE 标志 来 分 配 的 ,一 旦 使 用 完毕 ， 就 可 以 立 
即使 用 kghfre(0) 来 释放 。 

О RECREATEABLE: 这 类 Chunk 是 通过 KGHACRECR 标志 来 分 配 的 ， 可 以 被 锁 住 或 者 解 


锁 。 调 用 者 可 以 使 用 KGHPIR 来 锁 住 这 个 Chunk, 也 可 以 通过 KGHUPR 来 解锁 这 个 Chunk。 
当 这 种 Chunk 被 解锁 后 ， 通 过 LRU 机 制 进行 管理 。 当 调用 kghuprO 的 时 候 ， 调 用 者 会 传 
递 一 个 LATCH 参数 给 HEAP MANAGER, HEAP MANAGER 在 使 用 kghfre() 释 放 这 个 
Chunk 的 时 候 ， 会 使 用 此 LATCH。 
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口 FREEABLE WITH MARK: 类 似 于 FREEABLE, 不 同 的 是 这 类 Chunk 包含 一 个 корк), 
当 Chunk 使 用 的 空间 达到 kghmrkO 对 应 的 值 时 ， 该 Chunk 才能 被 释放 。 

另外 ， 不 管 堆 类 型 如 何 ， 都 可 以 拥有 子 堆 ， 比 如 SHARED POOL 就 是 SGA HEAP 的 子 堆 。 

下 面 我 们 来 看 看 如 何 创建 堆 。 堆 创建 包含 两 个 步骤 , 一 是 初始 化 堆 的 句柄 ,二 是 给 堆 分 配 空 
间 。 创 建 堆 时 ， 首 先 通 过 kghini() 来 初始 化 堆 句 柄 。 一 个 堆 句 柄 包括 一 组 FREE LIST BUCKETS 
和 相应 的 SIZE 参数 。 调 用 kghini0 时 ,需要 使 用 两 个 十 分 重要 的 宏 : KGHDS fll KGHDSSIZ, 前 
者 定义 了 堆 的 FREE LIST BUCKETS 的 数量 ， 后 者 定义 了 句柄 的 大 小 。 调 用 kghiniO 的 重要 参数 
包括 : 
о 堆 的 扩展 大 小 (EXTENT_SIZE ); 
О 堆 的 FREELIST BUCKETS 的 数量 ( FREE, МОМ); 
口 包含 每 个 FREE LIST BUCKETS 大 小 的 数组 ( FREE, SIZE ); 
а 包含 每 个 FREELIST BUCKETS 类 型 的 数组 ( FREE NTYPE )。 

每 个 FREE LIST 包含 相同 的 ALLOCATION CLASS 的 Chunk。 当 一 个 Chunk 释放 的 时 候 ， 
会 被 放 人 到 小 于 或 等 于 该 Chunk ff) FREE LIST 中 去 。 在 FREE LIST 里 ，Chunk 不 按照 大 小 排序 。 

通过 kghini() 的 参数 ， 可 以 猜测 Oracle 堆 的 基本 思路 ， 比 如 ， 我 们 从 SGA 中 分 配 一 个 堆 用 
于 共享 池 , 在 分 配 共 享 池 的 时 候 , 需要 确定 每 个 堆 的 扩展 大 小 。 另外 还 需要 知道 堆 的 FREE LIST 
BUCKETS 的 数量 ,这 一 点 很 多 DBA 在 学 习 共 享 池内 部 原理 的 时 候 都 已 经 有 所 了 解 , 对 于 Oracle 
8i 或 者 更 早 的 版 本 ， 共 享 池 的 FREE LIST 包含 10 个 Bucket， 从 9i 开 始 ，FREE LIST 包含 256 
个 Bucket。 同 时 ， 我 们 还 需要 一 个 数组 ， 来 指明 FREE LIST BUCKETS 中 每 个 Bucket 存放 的 
Chunk 的 大 小 ,同时 用 一 个 数组 来 存放 每 个 Bucket 的 FREE 类 型 。 通 过 这 些 参数 ,调用 kghini() 
就 可 以 从 父 堆 中 分 配 内 存 了 。 分 配 的 内 存 会 被 挂 载 到 FREE LIST 上 ， 这 时 堆 就 处 于 可 用 的 初始 
化 状态 了 。 

下 面 通过 一 个 Oracle 8.1.5 的 共享 池 的 转 储 信息 来 验证 上 述 概念 。 


FREE LISTS 
Bucket 0 size=44 


Chunk 52fblc4 sz= 60 ree 
Chunk 5161394 sz= 40 ree 
Chunk 5164904 sz= 48 ree 
Chunk 516fbcc sz= 28 ree 
Chunk 5195570 sz= 52 ree 
Bucket 1 size=76 

Chunk 5180938 sz= 76 ree 
Chunk 5lcb58c sz= 84 ree 
Chunk 51bf194 sz= 88 ree 
Chunk 5laf3e0 sz= 84 ree 
Chunk 5lac298 sz= 76 ree 
Chunk 51с3818 sz= 76 ree 
Chunk 51f04d0 sz= 92 ree 
Chunk 5212c90 sz= 92 ree 
Chunk 5290280 sz= 76 ree 
Chunk 52c¢2248 sz= 84 ree 
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Chunk 52c3784 sz= 80 ree 
Chunk 52dbb5c sz= 92 ree 
Chunk 52df980 sz= 92 ree 
Chunk 52e0aa4 sz= 88 ree 
Bucket 2 size=140 

Bucket 3 size=268 

Chunk 516325c sz= 472 ree 
Bucket 4 size=524 

Bucket 5 size=1036 

Chunk 5160be8 sz= 1080 ree 
Bucket 6 size=2060 

Chunk 516d3cc sz= 2812 ree 
Bucket 7 size=4108 

Bucket 8 size=8204 

Bucket 9 size=16396 

Bucket 10 size=32780 

Chunk 4c69598 sz= 5204008 free 

Total free space = 5212456 


可 以 看 到 ,共享 池 的 FREELIST 共 有 10 个 Bucket, 其 中 Bucket0 存 放 所 有 小 于 76B 的 Chunk, 
Bucket 10 存放 所 有 大 于 32780B 的 Chunk。 其 他 Bucket 存放 的 都 是 大 于 其 Size 大 小 、 小 于 下 一 
个 Bucket 的 Size 大 小 的 Chunk。 我 们 要 注意 的 另外 一 点 是 ，Bucket 中 的 Chunk 不 是 按照 大 小 排 


序 的 。 


如 果 需 要 从 Chunk 中 分 配 空间 ， 可 以 通过 调用 kghalo0 来 实现 ,这 个 调用 返回 指向 Chunk = 
间 的 指针 。 在 调用 kghalo0 时 ， 需 要 分 配 的 空间 的 大 小 通过 REQ_SIZE 参数 传递 ， 但 是 HEAP 
MANAGER 不 一 定 分 配 申 请 的 大 小 空间 ， 而 是 根据 判断 ， 分 配 一 个 被 称 为 ACTUAL_SIZE 的 空 
la], ACTUAL SIZE 可 能 比 REQ_SIZE 大 或 者 小 ， 这 一 切 都 是 根据 当前 拥有 空间 的 情况 ,以 及 此 
类 Chunk 的 分 配 特 性 来 判断 的 ， 并 不 是 无 规律 的 。 从 Chunk 中 分 配 空间 的 基本 顺序 如 下 。 


а 首先 搜索 FREELIST 上 是 否 存在 可 以 释放 的 Chunk. 
a 如 果 没 找到 ,就 查找 是 否 有 RECREATEABLE 的 Chunk 可 以 释放 ,释放 已 经 使 用 的 Chunk, 


| 另外 一 个 链表 ， 就 是 LRU 链表 。LRU 链表 根据 使 用 频繁 程度 ， 通 过 一 个 双向 链 


来 串联 已 经 被 分 配 的 Chunk。 如 果 在 LRU 链 中 找到 了 可 以 释放 的 Chunk， 就 通知 HEAP 
MANAGER 去 释放 ， 如 果 该 Chunk 是 被 锁 住 的 ， 首 先 要 解锁 ， 然 后 才能 释放 。HEAP 
MANAGER 在 释放 内 存 时 ,会 自动 合并 碎片 。 实 际 上 这 个 释放 RECREATEABLE 的 Chunk 


的 过 程 入 


0 我 们 做 FLUSH SHARED POOL 操作 是 类 似 的 ， 只 是 其 规模 要 小 得 多 。HEAP 


MANAGER 释放 Chunk 的 时 候 有 一 个 条 件 ， 一旦 释放 后 已 经 存在 足够 分 配 的 Chunk, 26 
么 这 个 释放 过 程 就 会 结 


口 如 果 此 时 还 没有 找到 可 以 释放 的 Chunk， 就 从 父 堆 里 分 配 空闲 的 空间 。 
а 如 果 父 堆 无 法 分 配 空间 ， 那 么 就 会 报错 。 


在 分 配 空间 的 时 候 ， 如 果 要 在 FREELIST 中 查找 , 那么 首先 会 根据 需要 分 配 空间 的 大 小 , dX 
到 相应 的 Bucket ( 每 个 Bucket 都 有 一 个 最 大 值 ， 指 明 该 Bucket 中 的 空闲 Chunk 不 会 超过 某 个 特 
定 的 值 ， 找 到 最 大 值 小 于 或 等 于 分 配 值 的 最 大 Bucket )， 然 后 搜索 整个 链表 。 如 果 找 到 了 大 小 正 
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好 相同 的 Chunk, 那么 就 直接 分 配 使 用 。 如 果 找 不 到 合适 的 Chunk, 就 会 选择 一 个 稍 大 的 Chunk， 
然后 分 裂 空间 , 将 该 Chunk 分 裂 为 两 个 Chunk, 一 个 和 所 分 配 空间 大 小 一 致 , 一 个 是 剩 下 的 空间 。 
最 后 将 剩 下 的 空间 根据 大 小 挂 载 到 相应 的 Bucket 的 双向 链表 上 。 

如 果 要 释放 一 个 扩展 的 空间 ， 可 以 通过 kghfre0 调 用 来 实现 。 在 调用 时 ， 要 让 所 有 正在 使 用 
这 个 扩展 的 会 话 完成 执行 ， 释 放 或 者 解锁 相关 的 对 象 ， 然 后 才能 释放 扩展 。 

要 释放 堆 中 的 所 有 扩展 ， 可 以 调用 kghfrh()。 不 过 在 释放 堆 之 前 ， 必 须 先 释放 所 有 的 子 堆 。 
在 子 堆 里 释放 所 有 的 扩展 ， 可 以 调用 kehfruO о 

上 面 的 这 些 文字 ,对 于 没有 任何 程序 开发 经 验 的 人 来 说 , 确实 有 些 难以 理解 。 其 实 老 白 已 经 
将 堆 的 算法 做 了 最 大 程度 的 精简 ， 和 否则 大 家 就 更 是 一 头 雾 水 了 。DBA 理解 堆 的 一 些 基 本 算法 有 
什么 好 处 呢 ? 实际 上 , 我 们 平时 对 于 Oracle 的 堆 管理 , 特别 是 共享 池 的 管理 , 存在 一 些 认 识 上 的 
误区 ， 而 通过 对 堆 的 一 些 基 本 原理 和 算法 的 理解 ， 可 以 帮助 我 们 纠正 这 些 错误 。 

首先 是 共享 池 碎 片 化 的 问题 。 根 据 堆 的 内 存 管 理 方法 ,很 容易 可 以 看 出 ,其 实 碎 片 化 是 不 可 
避免 的 ,共享 池 使 用 一 段 时 间 之 后 ,肯定 会 出 现 碎 片 化 的 趋势 ， 而 且 随 着 数据 库 实 例 启动 时 间 的 
增长 ， 这 种 碎片 化 趋势 会 越 来 越 明 显 。 但 是 共享 池 碎 片 化 并 不 等 于 共享 池 就 有 问题 ， 虽 然 说 碎片 
化 的 共享 池 效 率 可 能 会 有 所 下 降 ， 但 是 一 般 情况 下 都 在 可 以 接受 的 范围 和 内， 因此 DBA 不 需要 过 
多 地 担心 这 个 问题 ， 不 要 谈 虎 色 变 。 

接 下 来 要 讨论 的 一 个 问题 是 共享 池 使 用 率 的 问题 。 很 多 DBA 看 到 共享 池 使 用 率 比 较 高 ， 就 
十 分 紧张 ,担心 共 享 池 快 用 完了 会 出 问题 。 如 果 了 解 了 堆 的 内 存 分 配 和 管理 策略 ， 就 不 会 有 这 样 
的 担心 了 。 既 然 分 配 了 那么 多 的 共享 池 , 那 就 尽情 地 用 吧 ， 只 有 把 共享 池 全 部 用 掉 了 ,才能 充分 
达到 共享 游标 和 字典 的 好 处 。 反 倒是 共享 池 使 用 率 不 高 ,资源 不 能 充分 地 利用 , 才 是 值得 头痛 的 
事情 。 因 此 我 们 不 能 通过 共享 池 的 使 用 率 来 判断 其 是 和 否 存在 隐患 。 有 时 候 共 享 池 使 用 率 只 有 5096, 
但 是 可 能 性 能 并 不 好 ; 而 有 时 候 共 享 池 总 是 接近 100% 的 使 用 率 , 但 是 却 没 有 任何 问题 。 

第 三 个 要 讨论 的 问题 就 是 ， 如果 共 享 池 的 争 用 很 严重 , 但 是 共享 池 的 使 用 率 又 并 不 高 ， 这 说 
明 什 么 ?这 也 是 困扰 了 老 白 很 多 年 的 问题 。 老 白 也 经 常 磁 到 一 些 系统 , 共享 池 相 关门 锁 争 用 十 分 
严重 , 大 多 数 情 况 下 , 共享 池 争 用 严重 是 由 于 共享 池内 存 不 足 导 致 的 , 但 是 进行 分 析 后 发 现 共享 
池 的 使 用 率 并 不 高 ,只 有 60% 左 右 。 这 是 为 什么 呢 ? 老 白 了 解 了 共享 池内 存 分 配 算法 后 , 才 想 明 
白 了 这 其 中 的 道理 .如 果 内 存 分 配 十 分 频繁 ,那么 共享 池 的 FREELIST 上 的 Chunk 会 被 优先 使 用 ， 
共享 池 的 使 用 率 就 会 持续 上 升 。 而 如 果 共 享 池 使 用 率 不 高 , 那么 就 说 明 共 享 池 争 用 并 不 是 由 于 分 
配 内 存 十 分 频繁 。 那 又 是 怎么 回 事 呢 ? 我 想 刚 刚 看 了 本 节 的 有 些 朋友 已 经 有 答案 了 , 十 分 频繁 的 
未 被 分 配 内 存 的 访问 , 肯定 是 访问 可 重用 的 数据 了 。 什么 情况 下 才 可 能 出 现 这 样 的 争 用 呢 ? 很 明 
显 , 软 分 析 就 是 十 分 典型 的 这 类 访问 。 于 是 问题 就 变 得 简单 了 , 减少 软 分 析 就 可 以 缓解 这 个 问题 。 
那么 , 加 大 SESSION. CACHED CURSORS IE, 老 白 把 这 个 参数 调整 到 200， 再 一 分 析 ， do 
的 使 用 率 达 到 了 90% ， 共 享 池 的 争 用 减少 了 。 

第 四 个 问题 是 什么 情况 可 能 导致 共享 池 出 现 ORA-4031 呢 ? 老 白 最 初 接触 共享 池 的 时 候 , 总 
觉得 共享 池 既 然 是 可 以 通过 LRU 算法 换 出 的 ,那么 应 该 不 会 出 现 不 足 的 情况 啊 。 随 着 对 共享 池 
内 存 分 配 和 管理 算法 的 研究 深入 , 才 发 现 释放 共享 池内 存 是 有 条 件 的， 当前 被 锁 住 的 内 存 是 不 能 
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释放 的 。 如 果 当 前 正好 有 个 会 话 在 执行 , 那么 其 游标 相关 的 所 有 内 存 对 象 必须 是 锁 住 的 ,不 能 
便 释 放 ， 否 则 这 个 SQL 的 执行 就 会 出 现 问题 。 正 因为 这 样 ， 在 系统 并 发 量 很 大 的 时 候 ， 由 于 很 
多 共享 池 的 内 存 是 被 锁 住 无 法 释放 的 , 共享 池 的 空闲 空间 就 被 分 割 为 无 数 个 很 小 的 碎片 , 可 能 
法 满足 一 些 较 大 的 分 配 ， 出 现 ORA-4031 也 就 不 可 避免 了 。 在 这 种 情况 下 ,我 们 可 以 认为 共享 池 
不 足 导致 了 问题 ， 如 果 共 享 池 的 空间 再 大 一 点 ， 出 现 内 存 不 足 的 可 能 性 也 就 会 下 降 。 除 了 共享 池 
ANE, 还 有 什么 情况 可 能 导致 ORA-4031 呢 ? 前 面 所 说 的 那 种 情况 ， 是 由 于 系统 并 发 量 很 大 ,大 
量 的 共享 池内 存 被 锁 住 而 无 法 释放 。 一 旦 系统 负载 下 降 , 共享 池 就 会 逐渐 恢复 正常 。 另 外 一 种 情 
况 就 是 ， 共 享 池 中 的 一 些 LIST WK (比如 LOCK、RESOURCE 等 ) 初始 化 分 配 了 一 部 分 空间 ， 
如 果 这 部 分 列表 用 完了 ， 可 以 动态 扩展 。 由 于 这 些 扩展 是 永久 性 的 ， 所 以 ,它们 就 像 共享 池 中 钉 
下 的 一 颗 颗 钉子 , 是 无 法 拔 掉 的 。 如 果 这 类 扩展 十 分 频繁 , 那么 时 间 长 了 , 共享 池 就 会 被 这 些 “ 钉 
子 ” 分 割 为 很 多 碎片 。 这 种 碎片 化 是 永久 性 的 ， 随 着 实例 启动 时 间 的 推移 ， 会 越 来 越 严重 ， 而 且 
无 法 自动 或 者 手工 修复 。 积 累 到 一 定 程度 ， 这 个 系统 就 会 出 现 严重 的 碎片 化 问题 ， 从 而 出 现 
ORA-4031， 甚 至 导致 宕 机 。 对 于 这 种 系统 ， 一 般 来 说 可 以 通过 三 个 渠道 来 优化 : 第 一 个 渠道 是 
加 大 共享 池 , 使 之 碎片 化 的 时 间 推 迟 , 但 是 这 只 是 延迟 碎片 化 ,不 能 避免 碎片 化 ; 第 二 个 渠道 是 
定期 重启 实例 ， 通 过 重启 实例 ， 恢 复 共享 池 的 内 存 空间 ， 确 保 系 统 正常 运行 ， 不 出 现 宕 机 现象 ， 
不 过 要 做 到 这 一 点 , 对 于 大 多 数 7 x 24 的 系统 来 说 十 分 困难 ; 第 三 个 是 扩大 经 常 动态 扩展 的 列表 
对 象 的 初始 大 小 , 减少 其 动态 扩展 的 次 数 ,最 好 能 够 让 它们 不 再 动态 扩展 ， 这 个 做 法 会 浪费 一 定 
的 共享 池 空 间 ， 但 却 是 解决 这 个 问题 最 好 的 方法 。 

似乎 问题 都 解决 了 ， 好像 共享 池 也 没 那 么 复杂 嘛 ， 只 要 给 共享 池 足 够 的 空间 ， 它 就 会 很 好 地 
工作 了 。 实 际 上 并 没有 这 么 简单 。 还 是 接着 刚才 ORA-4031 的 问题 往 下 讨论 吧 。 如 果 分 配 了 很 大 
的 共享 池 ， 经 过 一 段 时 间 的 运行 后 ， 它 变 得 很 零碎 了 ， 这 时 我 们 要 分 配 一 个 较 大 的 连续 空间 。 共 
享 池 中 没有 这 么 大 的 Chunk 可 用 , 那么 就 会 开始 释放 空间 , 而 释放 空间 的 时 候 , 需要 持 有 共享 池 
的 门 锁 ， 因 此 在 释放 共享 池 空 间 时 ， 为 了 确保 共享 池 门 锁 被 持 有 的 时 间 不 会 太 长 ，Oracle 内 部 对 
释放 Chunk 的 数量 做 了 限制 ， 一 旦 超过 这 个 限制 ， 这 个 小 型 的 FLUSH 操作 就 会 停止 。 这 种 情况 
下 ， 虽 然 共享 池 中 的 空闲 空间 是 足够 分 配 的 ,但 也 会 出 现 ORA-4031 错误 。 另 外 由 于 大 量 碎片 释 
放 时 ,共享 池 门 锁 是 被 持 有 的 ,并 发 的 其 他 会 话 也 会 受到 一 定 的 影响 。 因 此 在 共享 池 碎 片 化 特别 
严重 的 时 候 ,， 出 现 共享 池 性 能 故障 和 ORA-4031 的 可 能 性 就 会 大 大 增加 。 所 以 我 们 在 理解 共享 池 
的 工作 原理 并 将 其 应 用 在 实际 工作 中 时 ， 还 是 不 能 过 于 简单 化 。 


3.1.1 进一步 了 解 共享 池 


顾名思义 , 共享 池 就 是 Oracle 数据 库 所 有 会 话 所 共享 的 缓冲 池 。 共享 池 里 存放 的 也 是 需要 给 
所 有 会 话 共享 的 数据 。 前 面 已 经 简单 介绍 过 一 些 共享 池 的 内 容 , 以 及 内 存 分 配 释放 的 算法 , 这 里 
就 不 多 做 措 述 了 。 本 闻 主 要 介绍 共享 池 的 基本 构造 以 及 相关 的 算法 。 通 过 对 这 些 知 识 的 了 解 , x 
者 可 以 掌握 一 些 共享 池 分 析 和 优化 的 思路 。 

一 般 情 况 下 , 学 习 共享 池 的 知识 以 及 优化 的 技巧 , 不 一 定 需 要 转 储 共享 池 。 不 过 对 于 想 更 加 
深入 了 解 共享 池 的 朋友 , 转 储 共享 池 则 是 学 习 共享 池内 部 结构 过 程 中 必 不 可 少 的 步骤 。 老 日 要 事 
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先 声 明 的 是 ,共享 池 的 结构 十 分 复杂 , 不 建议 初学 者 去 分 析 共 享 池 的 转 储 ， 如 果 你 对 共享 池 还 缺 
乏 深 入 的 了 解 ,甚至 不 知道 共享 池 的 主要 用 途 是 什么 ,那么 面 对 几 百 兆 甚 至 几 十 千 兆 的 转 储 文件 ， 
恐怕 会 朋 溃 的 。 想 要 深入 了 解 共享 地， 就 需要 了 解 把 共享 池 的 内 容 转 储 到 文件 的 基本 命令 ， 以 下 
命令 可 以 把 LIBRARY. CACHE 的 内 容 转 储 到 TRACE 文件 中 : 

ALTER SESSION SET EVENTS 'immediate trace name LIBRARY_CACHE level <level>'; 


其 中 <level> 代 表 Level 级 别 ， 对 于 9.2.0 及 更 高 版 本 ， 不 同 Level 的 含义 如 下 所 示 。 

口 Level=1， 转 储 库 缓存 统计 信息 。 

口 Level=2， 转 储 散 列表 概要 。 

口 Level=4， 转 储 库 缓 存 对 象 ， 只 包含 基本 信息 。 

口 Level=8， 转 储 库 缓存 对 象 ， 包 含 详细 信息 (包括 child references, pin waiters 等 )。 
口 Level=16， 增 加 堆 大 小 信息 。 

口 Level=32， 增 加 堆 信息 。 

和 前 一 节 所 介绍 的 堆 管理 一 样 ， 共 享 池 也 通过 Free List 管理 空闲 块 ，EFree List 按 不 同 大 小 划 
分 Bucket。 在 Oracle 8i "P, Oracle 把 所 有 的 空闲 内 存 链接 在 10 个 Bucket E, TE Oracle 9i t}, 
Oracle 把 空闲 的 内 存 链接 在 255 个 Bucket 上 。 

Oracle 8i 管理 Free List 的 方法 是 ， 把 所 有 的 空闲 块 都 放 在 10 个 Bucket 中 ， 小 于 76B 的 块 都 
位 于 Bucket 0 E; 大 于 32780B 的 块 ， 都 在 Bucket 10 上 。 数 据 库 启 动 以 后 ， 共 享 池 中 大 多 数 是 
连续 内 存 块 ， 当 空间 分 配 使 用 以 后 ， 内 存 块 开始 被 分 制 ， 碎 片 开 始 出 现 ，Bucket 对 应 的 Chunk 
链表 开始 变 长 。 当 数据 库 中 请 求 分 配 共享 池 空 间 时 ， 首 先进 入 相应 的 Bucket 进行 查找 ， 如 果 找 
不 到 ， 则 转向 下 一 个 更 大 的 内 存 块 Bucket， 获 取 第 一 个 Chunk， 分 割 这 个 Chunk， 剩 余部 分 会 进 
人 相应 的 Bucket， 进 一 步 增加 碎片 。 最 终 的 结果 是 ，Bucket0 上 的 内 存 块 会 越 来 越 多 ， 且 越 来 越 
人 碎 小 。 在 早期 的 Oracle 版 本 中 ,如果 每 个 Bucket 上 的 Chunk 多 于 2000 人 个， 就 被 认为 是 共享 池 碎 
片 过 多 , 不 过 随 着 共享 池 的 容量 越 来 越 大 ,经 过 一 段 时 间 的 运行 后 ，Bucket 0 的 Chunk 数量 可 能 
变 成 一 个 十 分 庞大 的 数字 ,高 达 数 万 甚至 更 多 ,而 在 大 多 数 情 况 下 ,， 我们 请 求 的 都 是 相对 较 小 的 
Chunk, 这 样 搜索 Bucket 0 往往 消耗 了 大 量 的 时 间 以 及 资源 。 这 可 能 会 使 共享 池 门 被 长 时 间 持 有 ， 
导致 更 多 的 共享 池 竞 和 争 。 对 于 Oracle 9i 之 前 的 数据 库 ， 由 于 Bucket 的 数量 太 少 ， 因 此 如 果 共 享 
池 比 较 大 ， 实 例 启动 一 定时 间 后 ，Bucket0 的 Chunk 数量 会 变 得 十 分 丐 大， 共享 池 的 效率 会 有 所 
下 降 ， 门 锁 争 用 也 会 越 来 越 严重 。 这 个 时 候 ， 如 果 刷 新 一 下 共享 地， 系统 性 能 会 有 很 大 的 回升 。 
实际 上 , 很 多 Oracle 9i 的 系统 也 存在 这 样 的 问题 ,共享 池 碎 片 化 的 程度 会 相当 高 ,系统 运行 一 段 
时 间 后 就 必须 刷新 共享 池 了 ,特别 是 那些 会 话 数 量 很 多 、 并 发 量 很 大 的 系统 。 几 年 前 , 老 白 就 碰 
到 过 这 样 一 个 案例 ， 这 个 系统 有 上 千 个 会 话 ， 业 务 高 峰 期 活跃 的 会 话 数 量 高 达 200 ~ 300 个 ,而 
数据 库 服 务 需 的 配置 很 低 ， 仅 有 16GB ， 因 此 能 够 给 共享 池 分 配 的 空间 也 十 分 有 限 ， 这 个 系统 运 
行 一 段 时 间 后 性 能 就 会 明显 下 降 。 经 过 分 析 , 我 们 发 现 是 共享 池 碎 片 化 导致 的 性 能 下 降 , 于 是 建 
议 客 户 每 天 晚上 业务 不 忙 的 时 候 手 工 刷 新 一 下 共享 池 ， 系 统 就 变 得 比较 稳定 了 。 

在 Oracle 9i F, Free Lists 被 划分 为 0~ 254 d£ 255 个 Bucket。 每 个 Bucket 容纳 的 大 小 范围 
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如 下 。 

口 Bucket 0 ~ 199 容纳 的 大 小 以 4 递增 。 

O Bucket 200 ~ 249 容纳 的 大 小 以 64 递增 。 
О Bucket 249: 4012 ~ 4107=96。 

О Bucket 250: 4108 ~ 8203-4096, 

О Bucket 251: 8204 ~ 16395-8192, 

О Bucket 252: 16396 ~ 32779-16384, 

О Bucket 253: 32780 ~ 65547-32768, 

口 Bucket 254: 265548. 

在 Oracle 9i 中， 对 于 较 小 的 Chunk, Oracle 增加 了 更 多 的 Bucket 来 管理 。0 ~ 199 Ж 200 4 
Bucket， 大 小 以 4 为 步 长 递增 ; 200 ~ 249 共 507 Bucket， 大 小 以 64 递增 。 这 样 每 个 Bucket 中 
容纳 的 Chunk 数量 大 大 减少 ， 查 找 的 效率 得 以 提高 。 这 就 是 Oracle 9; 中 共享 池 管理 的 增强 ， 通 
过 这 个 算法 的 改进 ，Oracle 8i 中 过 大 共享 池 带 来 的 门 锁 争 用 等 性 能 问题 在 某 种 程度 上 得 以 解决 。 
通过 内 部 视图 X$KSMSP 可 以 监控 共享 池 碎 片 的 情况 , 这 个 视图 中 的 每 一 行 代表 共享 池 中 的 
每 个 块 (chunk )。 以 下 几 个 字段 可 以 帮助 我 们 了 解 共享 池 的 情况 : 

OQ KSMCHCOM 是 注释 字段 ， 每 个 内 存 块 被 分 配 以 后 ， 注 释 会 添加 在 该 字段 中 。 
口 KSMCHSIZ 代表 块 大 小 。 
口 X$KSMSP.KSMCHCLS 列 代表 类 型 ， 主 要 有 4 类 : 

m FREE: free chunks 不 包含 任何 对 象 的 块 ， 可 以 不 受 限 制 地 被 分 配 。 

m RECR recreatable chunks 包含 可 以 被 临时 移出 内 存 的 对 象 ， 在 需要 的 时 候 ， 这 个 
对 象 可 以 被 重新 创建 。 例 如 ， 许 多 存储 共享 SQL 代码 的 内 存 都 是 可 以 重建 的 。 

m FREEABL: freeable chunks 包含 会 话 周 期 或 调用 的 对 象 ， 随 后 可 以 被 释放 。 这 部 分 
内 存 有 时 可 以 全 部 或 部 分 提前 释放 。 但 需要 注意 的 是 ， 由 于 某 些 对 象 是 中 间 过 程 产生 
BJ, 这些 对 象 不 能 临时 被 移出 内 存 ( 因为 不 可 重建 )。 

m PERM: permanent memory chunks 一 一 包含 永久 对 象 ， 通 常 不 能 独立 释放 。 

通过 查询 X$KSMSP 视图 来 考察 共享 池 中 存在 的 内 存 碎片 数量 。 这 里 要 注意 ，Oracle 的 某 些 
版 本 (如 10.1.0.2 ) 在 某 些 平台 上 (如 HP-UX, PA-RISC, 64-bit) 查询 该 视图 可 能 导致 过 度 的 
CPU 耗 用 ， 这 是 由 Bug 引起 的 。( 对 这 张 视图 的 访问 会 产生 KGHDUP 操作 ， 执 行 过 程 中 会 影响 
共享 池 的 门 锁 ，, 因此 在 业务 高 峰 期 , 应 尽 可 能 减少 对 该 视图 的 访问 , 而 且 最 好 由 DBA 手动 完成 。 
有 很 多 监控 系统 经 常 定期 采集 该 视图 的 数据 , 这 是 存在 一 定 风险 的 ， 有 时 候 会 导致 共享 池 严 重 冲 
突 ， 甚 至 可 能 导致 实例 被 挂 起 。) 对 应 示例 如 下 。 

首先 准备 一 个 数据 库 ， 在 刚刚 启动 的 时 候 ， 查 询 XSKSMSP. 


SQL> select count(*) from x$ksmsp; 
COUNT(*) 


2691 
SQL» SELECT a. ksmchcom, SUM (a. CHUNK) CHUNK, SUM (a.recr) recr, SUM (a.freeabl) 
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freeabl 

2 SUM (a.SUM) SUM 

3 FROM (SELECT ksmchcom, COUNT (ksmchcom) CHUNK 

4 DECODE (ksmchcls, 'recr', SUM (ksmchsiz), NULL) recr 

5 DECODE (ksmchcls, 'freeabl', SUM (ksmchsiz), NULL) freeabl 

6 SUM (ksmchsiz) SUM 

1 FROM x$ksmsp GROUP BY ksmchcom, ksmchcls) a 

8 GROUP BY a.ksmchcom 
KSMCHCOM CHUNK RECR FREEABL SUM 
Global Context 1 224 224 
KGK contexts 2 2316 2316 
KGK heap 2 3812 3812 
KGL handles 554 186404 186404 
KGLS heap 446 220536 391028 611564 
KQR PO 653 296324 296324 
KWQl bufq Heap 1 200 200 
LISTEN ADDRESS 9 1676 1676 
LISTEN ENDPOINT 1 1032 1032 
MS alert log 1 10252 10252 
MITR advisory 4 216 12144 12420 
PARAMETER ENTRY 3 92 92 
PARAMETER TABLE 1 1032 1032 
PLS cca hp desc 1 200 200 
PLS non-lib hp 1 2096 2096 
PRESENTATION EN 1 20 20 
PRESENTATION TA 1 1032 1032 
SERVICE NAME EN 2 16 16 
SERVICE NAMES T 1 1032 1032 
character set m 1 142040 142040 
character set o 5 215892 215892 
fixed allocatio 47 1504 1504 
free memory 140 67194772 
joxs heap 1 92 92 
joxs heap init 1 4248 4248 
library cache 1696 248812 432356 681168 
listener addres 1 16 16 
multiblock rea 2 4144 4144 
obj htab chunk 12 86208 86208 
permanent memor 2 29302084 
reserved stoppe 12 240 
service names a 2 36 36 
session param v 9 152712 152712 
sim memory hea 20 4248 80712 84960 
sql area 505 489056 1109156 1598212 
table definiti 3 252 252 
trigger defini 2 324 1072 1396 
trigger inform 2 336 816 1152 
trigger source 1 88 88 
已 选择 39 fg, 
SQL> 
我 们 记 下 空闲 内 存 的 情况 ， 包 括 其 块 的 数量 ， 接 下 来 先 随便 执行 一 个 SQL 语句， 比如: 
SQL>SELECT * FROM DBA TABLES WHERE ROWUNM<10; 
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然后 再 次 执行 上 面 的 查询 语句 查看 共享 池 的 情况 。 
SQL» SELECT a.ksmchcom, SUM (a.CHUNK) CHUNK, SUM (a.recr) recr, SUM (a.freea 
freeabl 

2 SUM (a. SUM) SUM 

3 FROM (SELECT ksmchcom, COUNT (ksmchcom) CHUNK 

4 DECODE (ksmchcls, 'recr', SUM (ksmchsiz), NULL) recr 

5 DECODE (ksmchcls, 'freeabl', SUM (ksmchsiz), NULL) freeabl 

6 SUM (ksmchsiz) SUM 

1 FROM x$ksmsp GROUP BY ksmchcom, ksmchcls) a 

8 GROUP BY a.ksmchcom 
KSMCHCOM CHUNK RECR FREEABL SUM 
Global Context 1 224 224 
KGK contexts 2 2376 2316 
KGK heap 2 3812 3812 
KGL handles 582 195836 195836 
KGLS heap 450 224316 394564 618940 
KQR PO 703 323068 323068 
KWQl bufq Heap 1 200 200 
LISTEN ADDRESS 9 1676 1676 
LISTEN ENDPOI NT 1 1032 1032 
MS alert log 1 10252 10252 
MTTR advisory 4 216 12144 12420 
KSMCHCOM CHUNK RECR FREEABL SUM 
PARAMETER ENTRY 3 92 92 
PARAMETER TABLE 1 1032 1032 
PLS cca hp desc 1 200 200 
PLS non-lib hp 1 2096 2096 
PRESENTATION EN 1 20 20 
PRESENTATION TA 1 1032 1032 
SERVICE NAME EN 2 16 16 
SERVICE NAMES T 1 1032 1032 
character set m 1 142040 142040 
character set o 5 215892 215892 
fixed allocatio 47 1504 1504 
KSMCHCOM CHUNK RECR FREEABL SUM 
free memory 148 66824732 
joxs heap 1 92 92 
joxs heap init 1 4248 4248 
library cache 1801 263408 462132 125540 
listener addres 1 16 16 
modification h 1 2060 2060 
multiblock rea 2 4144 4144 
obj htab chunk 12 86208 86208 
permanent memor 2 29302084 
reserved stoppe 12 240 
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service names a 2 36 36 
KSMCHCOM CHUNK RECR FREEABL SUM 
session param v 9 152712 152712 
sim memory hea 20 4248 80712 84960 
sql area 584 541728 1336540 1878268 
table definiti 3 252 252 
trigger defini 2 324 1072 1396 
trigger inform 2 336 816 1152 
trigger source 1 88 88 


已 选择 40 行 。 

从 上 面 的 例子 可 以 看 出 ， 空 闲 内 存 的 容量 减少 了 370040B, ， 不 过 它 的 Chunk 数量 却 增加 了 。 
这 是 因为 SQL 解析 从 空闲 内 存 中 分 配 了 空间 ， 并 且 产 生 了 更 多 的 碎片 。 从 上 面 对 共 享 池内 部 管 
理 的 算法 特点 分 析 ， 可 以 得 出 以 下 几 点 结论 。 
о 比较 大 的 共享 池 会 带 来 一 定 的 系统 开销 ， 因 此 共享 池 不 是 越 大越 好 ， 特 别 是 在 Oracle 8i 
或 者 更 早期 版 本 的 数据 库 中 。 
a 在 9i 以 后 的 系统 中 ， 特 别 是 CPU 数量 较 多 的 大 型 SMP 系统 中 ， 较 大 的 共享 池 带 来 的 负 
影响 已 经 大 大 降低 了 。 大 家 可 以 根据 自身 需要 使 用 较 大 的 共享 池 。 
о 随 着 系统 的 运行 ， 共 享 池 的 碎片 将 增加 ， 共 享 池 门 锁 竞 争 也 会 增加 ， 因 此 应 将 一 些 常 用 
对 象 固定 到 共享 池 中 ， 并 且 定 期 刷新 共享 地， 这样 有 助 于 保证 系统 的 性 能 。 
а 对 于 7 х 24 的 系统 ， 定 期 刷新 共享 池 有 助 于 保持 共享 池 性 能 的 稳定 。 

这 里 我 们 仅仅 从 十 分 简单 的 角度 去 分 析 了 共享 池 空 闲 空间 管理 的 算法 ， 实 际 上 ，Oracle 共享 
池 的 管理 算法 要 复杂 得 多 。 数 据 库 实例 启动 并 运行 了 很 长 时 间 后 , 共享 池 碎 片 化 会 变 得 十 分 严重 ， 
这 样 就 会 导致 比较 大 的 共享 内 存 分 配 ( 比如 分 配 10KB 的 空间 ) 无 法 满足 需求 , 对 于 这 样 的 情况 ， 
实际 上 Oracle 已 经 有 很 好 的 应 对 措施 。Oracle 在 共享 池 中 设计 了 保留 池 , 这 个 保留 池 的 管理 和 共 
享 池 是 不 同 的 。 

Oracle 是 从 7.1.5 版 本 开始 支持 保留 池 的 ， 保 留 池 的 设计 目的 是 为 了 在 共享 池 碎 片 化 很 严重 
的 时 候 ， 还 能 够 有 一 部 分 保留 空间 ， 用 于 较 大 的 内 存 分 配 。 我 们 可 以 通过 参数 
SHARED POOL _ RESERVED_SIZE 来 设置 保留 池 的 大 小 , 不 过 一 般 情 况 下 , 可 以 不 设置 该 参数 ， 
这 样 Oracle 会 自动 设置 保留 凶 的 大 小 为 共享 池 的 5%。 但 在 共享 内 存 不 是 很 大 的 情况 下 , 5% 的 空 
间 可 能 不 是 十 分 充足 , 因此 在 一 些 并 发 量 很 大 的 系统 中 , 如 果 经 常 出 现 较 大 的 共享 内 存 分 配 需求 
无 法 满足 的 现象 ,那么 可 以 将 该 参数 设置 为 共享 内 存 的 10% 左 右 。 

保留 池 的 使 用 是 有 条 件 的 。 首 先 必须 是 在 共享 池 的 FREELIST 中 找 不 到 足够 大 的 Chunk, 其 
次 是 分 配 的 内 存 容量 要 大 于 SHARED POOL RESERVED MIN ALLOC 的 设 定 值 。 这 个 参数 从 
8i 开始 已 变 为 隐 含 参数 ， 即 _SHARED_POOL_RESERVED_MIN_ALLOC， 其 默认 值 为 4400， 也 
就 是 说 , 只 有 超过 4400B 的 内 存 分 配 才 被 认为 是 大 内 存 分 配 , 可 以 使 用 保留 池 的 空间 。 在 一 个 碎 
片 化 很 严重 的 系统 中 , 一 旦 某 个 后 台 进程 在 执行 一 个 关键 性 操作 的 时 候 无 法 分 配 到 空间 , 就 有 可 
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能 导致 数据 库 实 例 的 崩 演 ,而 一 些 常用 系统 对 象 的 大 小 往往 在 4000 ~ 4400B 。 因 此 在 碎片 化 很 严 
mm AAR HTF ORA-4031 导致 宕 机 的 系统 中 ， 将 这 个 参数 设置 得 小 一 点 ( 比如 4000 或 者 3800 ) 
是 十 分 有 必要 的 。 

从 Oracle 9i 开始 , 共享 池 是 可 以 动态 调整 的 , 在 数据 库 不 重启 的 前 提 下 , 我 们 可 以 通过 alert 
system set Shared_pool_size=.… 命 令 来 随时 动态 调整 共享 池 的 大 小 。 只 要 保证 调整 完毕 后 总 的 SGA 
容量 小 于 SGA MAX SIZE 即 可 。 这 个 新 特性 给 予 我 们 另 一 个 解决 共享 池 问 题 的 思路 ,在 必要 时 
可 以 加 大 该 参数 ,使 共享 池 拥 有 更 多 的 可 用 内 存 。 如 果 要 享受 这 个 功能 的 好 处 , 那么 我 们 必须 设 
置 СА МАХ SIZE 参数， 使 之 比 目 前 分 配 的 SGA 的 内 存 总 量 大 一 些 ， 这 些 预 留 的 空间 今后 将 
被 用 于 动态 扩充 某 个 可 动态 扩充 的 缓冲 池 ( 比如 共享 池 或 者 DB Cache ), 实 际 上 SGA_MAX SIZE 
预 留 的 部 分 内 存 并 没有 被 占用 , 而 只 是 在 操作 系统 中 “预约 ”而 已 , 这 部 分 内 存 只 有 在 扩充 SGA 
中 的 缓冲 池 时 才 会 被 真正 占用 。 不 过 ,我们 在 碰 到 共享 池 不 足 的 时 候 ， 遇 到 的 情况 往往 是 
SGA МАХ SIZE 参数 并 未 预先 设置 ， 这 时 就 只 能 先 减少 其 他 缓冲 池 的 配置 ， 然 后 再 去 扩大 共享 
池 。 这 个 被 迫 缩小 的 缓冲 池 通 常 就 是 DB Cache, 

反 过 来 ， 在 其 他 缓冲 池 不 足 的 时 候 ， 也 可 以 先 动态 缩小 共享 池 ， 然 后 再 去 扩充 其 他 缓冲 池 。 
不 过 这 种 反 操 作 具 有 一 定 的 风险 , 对 于 碎片 化 很 严重 并 且 并 发 量 很 大 的 系统 , 可 能 导致 系统 出 现 
短暂 的 挂 起 现象 ， 严 重 时 甚至 可 能 导致 实例 崩溃 。 

从 Oracle 10g 开始 ,我 们 就 可 以 使 用 共享 内 存 自动 管理 ( ASMM ) 功能 了 。 这 个 功能 开启 之 
后 (通过 设置 SGA_TARGET 参数 来 开启 此 功能 )，Oracle 将 自动 管理 共享 内 存 。 当 共享 池 不 足 
的 时 候 ，Oralce 会 自动 从 其 他 缓冲 池 中 释放 空间 ， 供 共享 池 扩充 使 用 。 同 样 ， 当 其 他 缓冲 池 不 足 
的 时 候 ， 也 会 自动 缩小 共享 池 来 扩充 该 缓冲 池 。 因 此 ,在 Oracle 10g 的 系统 中 ， 我 们 很 少 会 看 到 
ORA-4031 这 个 很 著名 的 错误 信息 了 。Oracle 也 在 其 官方 文档 中 建议 Oracle 10g 的 用 户 不 要 再 去 
设置 DB_CACHE SIZE, SHARED POOL SIZE 之 类 的 参数 了 ， 只 要 设置 一 个 合理 的 
SGA_TARGET 参数 就 足够 了 。 

这 一 切 看 上 去 似乎 很 美 , 我 们 只 要 使 用 共享 内 存 自 动 管理 就 可 以 了 , 而 不 需要 再 去 考虑 共享 
池 碎 片 、ORA-4031。 不 过 现实 是 残酷 的 ，Oracle 不 可 能 了 解 每 个 系统 的 复杂 性 。 简 单 地 设置 
SGA_TARGET 就 解决 所 有 问题 的 想法 也 有 点 太 天 真 了 。 在 一 个 负载 较 高 、 相 对 复杂 的 OLTP Ж 
统 中 ,负载 的 变化 是 十 分 多 样 的 。 比 如 ,早上 9 点 上 班 的 时 候 ， 可 能 突 发 大 量 的 并 发 操作 ， 做 一 
些 签到 、 登 录 的 OLTP 操作 ， 虽 然 每 个 操作 开销 不 大 ， 但 是 并 发 量 很 大 。 这 时 ，DB Cache 压力 
不 大 ， 而 共享 池 压 力 很 大 。 而 由 于 前 一 天 半夜 有 很 多 大 型 批 处 理 ， 会 使 用 大 量 的 DB Cache, [Al 
此 早上 8 点 多 钟 的 时 候 ， 共 享 池 已 经 被 压缩 得 很 小 了 。 这 时 ， 就 需要 缩小 DB Cache， 扩 大 共享 
池 。 如 果 恰 巧 某 些 部 门 需要 统计 一 些 数据 ,做 了 一 些 大 数据 量 的 统计 操作 ， 这 个 SGA RESIZE Т. 
作 就 会 变 得 十 分 复杂 ，Oracle 的 ASMM 机 制 可 能 会 无 所 适 从 ， 出 现 了 在 短 时 间 内 反复 压缩 扩展 
共享 池 的 现象 ， 就 可 能 会 产生 严重 的 SGA 性 能 问题 。 在 这 种 情况 下 ， 我 们 可 能 看 到 大 量 的 游标 
相关 等 待 ， 或 者 库 缓 存 等 待 。 

上 述 情况 ， 称 为 SGA 拌 动 。 为 了 防止 SGA 抖动 ， 我 们 可 以 关闭 自动 共享 内 存 管理 ( 设置 
SGA_TARGET 为 0), 也 可 以 为 共享 池 设 置 一 个 最 小 值 (通过 设置 SHARED. POOL. SIZE 可 以 设 
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定 共享 池 的 最 小 值 ， 因 为 自动 共享 内 存 管理 缩小 共享 池 时 ， 不 能 小 于 该 参数 指定 的 值 )， 从 而 减 
少 共享 池 拌 动 ， 保 障 共 享 池 的 性 能 不 会 受到 严重 的 影响 。 

男 外 一 个 关于 共享 池 的 热门 话题 是 共享 池 碎 片 和 共享 池 雄 片 化 的 问题 。 很 多 DBA 的 优化 目 
标 是 减少 共享 池 碎 片 甚至 消除 共享 池 碎 片 , 这 其 实 是 一 个 不 可 能 完成 的 任务 。 共 享 池 碎 片 化 的 趋 
势 是 共享 池 算 法 决定 的 , 经 过 一 段 时 间 的 运行 ,共享 池 的 碎片 化 趋势 表 定 是 越 来 越 明显 , 碎片 也 
必然 越 来 越 多 。 有 些 DBA 通过 共享 池 中 平均 Chunk 的 大 小 来 判断 共享 池 的 性 能 是 否 良 好 ， 实 际 
上 这 是 一 个 误区 。 共 享 池 碎片 化 的 程度 越 高 并 不 一 定性 能 就 越 差 ， 很 多 系统 的 共享 池 中 Chunk 
都 很 小 , 但 是 共享 池 的 性 能 并 不 存在 问题 。Oracle 一 直 在 想 办 法 设计 一 个 指标 ， 用 于 评估 共享 池 
的 性 能 ,不 过 到 目前 为 止 的 版 本 中 , 还 没有 提出 一 个 十 分 具有 代表 性 的 指标 。 根 据 这 些 年 对 共享 
池 的 理解 , 老 白 觉得 每 次 共享 池 请 求 扫描 的 Chunk 数量 越 高 ,共享 池 请 求 的 效率 就 越 低 , 也 就 说 
明 共享 池 的 碎片 化 程度 越 高 。 不 过 到 目前 为 止 ，Oracle 并 未 提供 这 个 指标 。 

实际 上 我 们 并 不 需要 对 共享 池 碎 片 化 程度 进行 直接 的 分 析 , 通过 共享 池 相 关门 锁 的 平均 等 待 
时 间 以 及 超时 的 次 数 ， 就 可 以 很 准确 地 判断 出 共享 池 的 效率 。 
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共享 池 的 子 池 (Sub Pool) 技术 是 从 Oracle 9i 才 开始 引入 的 。 子 池 技 术 解 决 了 较 大 的 共享 池 
在 并 发 访问 方面 的 性 能 问题 。 在 Oracle 8i 和 以 前 的 版 本 中 , 共享 池 是 没有 子 池 的 , 整个 共享 池 的 
分 配 和 释放 都 由 一 个 共享 池 门 锁 进 行 串 行 化 控制 。 

在 这 种 结构 下 , 共享 池 的 分 配 和 释放 可 能 会 成 为 一 个 瓶颈 ， 当 大 并 发 量 的 共享 池 分 配 释 放 请 
求 存在 的 时 候 , 共享 池 门 锁 这 个 瓶颈 点 就 十 分 明显 了 , 因此 引入 子 池 的 概念 是 十 分 必要 的 。 Oracle 
共享 池 的 子 池 充 分 利用 了 大 型 SMP 系统 多 CPU, 海量 内 存 的 特点 , 根据 CPU 的 数量 来 确定 子 池 
的 数量 。 其 基本 原则 是 ， 每 4 个 CPU 分 配 一 个 子 池 ， 最 多 可 分 配 7 个子 池 。 那 么 这 里 就 又 有 一 
个 问题 了 ， 如 果 某 个 系统 的 CPU 数量 很 多 ， 而 共享 池 的 容量 比较 小 ， 比 如 一 个 包含 32 个 CPU 
的 系统 ， 分 配 了 512MB 的 共享 地， 那么 按照 刚才 的 算法 ， 共 享 池 可 以 分 为 8 个 子 池 ， 每 个 子 池 
的 容量 就 只 有 64MB ， 这 人 么 小 的 子 池 ， 很 快 就 会 碎片 化 了 。 

这 一 点 Oracle 其 实 已 经 考虑 到 了 , 无 论 分 配 多 少 个 子 池 , 都 必须 确保 每 个 子 池 的 容量 不 小 于 
一 个 最 小 值 ， 这 个 最 小 值 在 Oracle 的 各 个 版 本 中 也 有 所 不 同 。 

О 9i; 128MB。 

О 10g: 256MB. 

О 116: 512MB, 

从 上 面 的 数据 可 以 看 出 , 随 着 Oracle 数据 库 版 本 的 更 新 , 子 池 容量 的 最 小 值 也 在 成 倍 地 增加 。 
这 说 明了 两 个 方面 的 问题 : 一 方面 是 随 着 硬件 的 发 展 ， 共 享 池 的 容量 也 在 不 断 增 长 ; 另 一 方面 ， 
Oracle 也 已 经 注意 到 了 ,， 子 池 过 小 所 导致 的 共享 池 碎 片 问题 可 能 会 带 来 严重 的 性 能 问题 ， 因 此 逐 
步 加 大 了 子 池 的 最 小 容量 。 

我 们 都 知道 ,共享 池子 池 的 数量 可 以 通过 参数 kghdsidx_count 来 指定 ,其 中 kghds 就 是 HEAP 
DESCRIPTION 的 结构 ， 如 代码 清单 3-1 所 示 。 
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代码 清单 3-1 
struct kghds í 


voi d * 指向 parent heap 的 指针 ; 

ub4 预先 分 配 的 大 小 ; 

void * unpin HEAP 时 传 入 的 OWNER 的 指针 ; 
kghhd * 开始 分 配 perment CHUNK 的 HD 指针 ; 
kghlu * 旧 扒 的 指针 ; 

kghhd * 堆 的 顶部 指针 ; 

b1 状态 位 ; 

KGHD9FEMPT BIT 0x01 // 是否 包 含 空闲 的 EXTENT 
KGHDSFINIT BIT 0x02 || 是否 已 经 初始 化 

KGHDSFALGN BIT 0x04 // 是 否 扩展 做 了 09 页 面 边界 对 齐 
KGHD9FPRFR BIT 0x08 // 是否 永久 性 的 Chunk 分 配 为 freeable 
ubl HEAP 中 的 FREELI9T9 的 数量 ; 

Char HEAP 用 途 描述 [ 15 41] ; 

b 2 HEAP 的 分 配 类 型 ; 

b 2 HEAP 类 型 ; 

ub2 HEAP 统计 类 型 ， 

ub2 HEAP 统计 


union kghds. UNK 10467782 HEAP 类 型 ， 


KGHDSALOF BIT 0x01 /] 总 是 分 配 freeable 的 CHUNK 
KGHDSFESZ BIT 0x02 / /固定 的 EXTENT 大 小 
KGHDSSESZ BIT 0x04 / /标准 EXTENT 大 小 
KGHD9FHEAP BIT 0x08 /] 不 扩展 HEAP 


} 

从 上 面 的 数据 结构 来 看 ,在 内 存 结构 上 ,共享 池 的 子 池 是 Shared Pool 这 个 HEAP 的 Sub Heap. 
每 个 子 池 都 有 一 个 KGHDS 结构 ， 要 访问 这 个 子 池 就 需要 通过 KGHDS 结构 。Oracle 的 思路 是 通 
过 多 CPU 的 特性 来 将 一 个 很 大 的 共享 池 划 分 为 若干 个 对 等 功能 的 区 间 ， 每 个 独立 的 区 间 都 有 相 
同 的 管理 机 制 ， 可 以 并 发 访问 ， 从 而 解决 性 能 方面 的 瓶颈 。 

在 具有 子 池 的 情况 下 ，Oracle 在 共享 池 中 分 配 空 间 的 算法 也 会 发 生 一 些 改变 。 比 如 ,在 没有 
子 池 的 情况 下 ， 如 果 想 在 共享 池 中 分 配 空间 ， 必 须 先 门 住 共享 池 门 锁 ， 如 果 无 法 获得 该 门 锁 ， 就 
需要 等 待 。 而 在 有 子 池 存在 的 情况 下 ,算法 发 生 了 改变 ， 如 果 某 个 系统 的 共享 池 有 6 个 子 池 ，, JE 
么 申请 共享 池 门 锁 可 以 从 0 号 子 池 开 始 ,一 直到 5 号 子 池 ， 每 个 子 池 都 有 一 个 共享 池子 门 锁 。 在 
申请 0~4 号 共享 池子 门 锁 的 时 候 ， 采 用 不 需 等 待 模式 ， 一 旦 申请 失败 ， 不 需要 等 待 ， 直 接 返 回 ; 
而 申请 5 号 子 池 的 共享 池子 门 锁 的 时 候 ， 就 需要 采用 等 待 模式 ， 直 到 获取 这 个 门 锁 为 止 。 

另外 一 种 情况 ,在 分 配 共享 池 空 间 的 时 候 ， 如 果 没 有 子 池 存 在 ， 当 共享 池 没有 足够 大 的 块 可 
以 使 用 时 , 会 通过 释放 一 些 可 释放 的 块 来 解决 这 个 问题 。 而 在 存在 子 池 的 情况 下 ， 如果 前 面 的 几 
个 子 池 没有 足够 大 的 块 可 分 配 , 那么 它 会 执行 类 似 无 子 池 的 操作 呢 , 还 是 会 继续 在 其 他 子 池 中 查 
找 空间 呢 ? 由 于 无 法 找到 关于 此 算法 的 描述 , 因此 我 们 也 只 能 根据 以 往 的 工作 经 验 进行 推测 。 代 
码 清单 3-2 所 示 的 查询 结果 可 能 能 够 解答 我 们 的 问题 。 
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代码 清单 3-2 

SQL» column indx heading "indxlindx пит" 
SQL» column kghlurcr heading "RECURRENT| CHUNKS" 
SQL» column kghlutrn heading "TRANSI ENT| CHUNKS" 
SQL» column kghlufsh heading "FLUSHED| CHUNKS" 
SQL» column kghluops heading "PINS AND| RELEASES" 
SQL» column kghlunfu heading "ORA- 4031| ERRORS" 
SQL» column kghluNFS heading "LAST ERROR| SIZE" 
SQL> selec 

2 indx, 

3 kghlurcr, 

4 kghlutrn, 

5 kghl uf sh, 

6 kghl uops, 

1 kghlunfu, 

8 kghl uNFS 

9 from 

10 sys.x$kghlu 

11 where 

12 inst id = userenv('Instance'); 


indx RECURRENT TRANSIENT FLUSHED PINS AND ORA- 4031 LAST ERROR 


indx num CHUNKS CHUNKS CHUNKS RELEASES ERRORS SIZE 
0 109782 817050 39672920 1.3463E+10 0 0 
1 226597 953890 41157199 8645642258 2854 3896 
2 34909 570914 41305725 1.0634E+10 0 0 
3 46802 785255 40361546 9380330002 0 0 
4 63663 766774 40506397 8444364769 0 0 
5 39275 762341 40270514 1.0518E+10 0 0 
6 101382 754076 40701740 1. 1389Е+10 0 0 


上 面 的 系统 中 ,共享 池 有 7 个 子 池 , 而 只 有 indx 为 1 的 子 池 出 现 了 ORA-4031 错误 ， 其 他 子 
池 中 并 没有 出 现 。 假 设 块 分 配 算法 在 某 个 子 池 无 法 分 配 空间 时 ， 就 从 其 他 子 池 中 去 分 配 , 那么 它 
选择 的 子 池 将 是 无 规律 的 ， 只 根据 获取 共享 池子 门 锁 的 情况 来 选择 ， 也 就 是 说 ，ORA-4031 错误 
不 会 集中 在 一 个 子 池 中 ， 而 会 分 布 在 多 个 子 池 中 ; 但 如 果 按 照 INDX 的 顺序 有 规律 地 选择 子 池 ， 
那么 ORA-4031 就 不 应 该 集中 在 INDX 为 1 的 子 池 中 ， 而 是 应 该 集中 在 INDX 为 6 或 者 INDX 为 
0 的 子 池 中 。 因 此 我 们 有 理由 推测 块 分 配 的 算法 是 : 一 旦 选择 在 某 个 子 池 分 配 空间 ( 前提 是 获取 
了 相关 的 共享 池 门 锁 )， 那 么 当 这 个 子 池 中 无 足够 的 空间 可 用 ， 而 且 无 法 使 用 保留 池 时 ， 此 次 分 
配 就 会 失败 ， 并 出 现 ORA-4031 报警 。 

关于 子 池 更 为 详细 的 算法 已 经 不 在 本 节 的 讨论 范围 之 内 了 ， 实 际 上 ОВА 们 也 不 需要 那么 深 
入 地 了 解 子 池 的 情况 。 我 们 只 需要 从 Oracle 子 池 的 一 些 基本 设计 思想 和 算法 中 了 解 共享 池子 池 管 
理 时 应 该 注意 的 问题 。 首 先 必 须 明 确 , 子 池 设置 的 目的 是 为 了 提高 共享 池 分 配 回 收 和 管理 的 性 能 ， 
加 大 共享 池 的 并 发 访问 能 力 ， 因 此 它 的 存在 肯定 能 够 提升 共享 池 的 性 能 。 其 次 , 我 们 必须 了 解 子 
池 技 术 可 能 带 来 的 负面 影响 , 由 于 一 个 大 的 共享 池 会 被 分 割 为 若干 个 较 小 的 子 池 , 每 个 子 池 独 立 
管理 Free List， 因 此 采用 子 池 后 ， 每 个 子 池 的 容量 变 小 了 ， 也 就 增加 了 共享 池 碎 片 化 的 可 能 性 。 
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知道 了 子 池 技术 的 两 面 性 ，DBA 应 该 了 解 在 实际 工作 中 如 何 使 用 子 池 技术 。 在 一 般 情况 下 ， 
我 们 可 以 不 用 理会 它 , 由 Oracle 自动 设置 子 池 即 可 。 而 如 果 共 享 池 经 常 出 现 一 些 碎片 问题 , 甚至 
是 ORA-4031 错误 ， 那 么 就 必须 减少 子 池 的 数量 ， 甚 至 禁用 子 池 。 

可 能 还 是 有 朋友 会 纠结 , 究竟 使 用 多 少 个 子 池 更 为 合适 呢 ? 这 一 点 确实 没有 定论 , 系统 分 配 
的 子 池 数量 在 大 多 数 情况 下 不 会 存在 严重 的 问题 。 不 过 在 共享 池 不 是 很 大 而 CPU 数量 很 多 的 情 
况 下 ， 我 们 还 是 要 十 分 注意 的 ， 特 别 是 在 % 版 本 的 数据 库 中 ， 子 池 的 最 小 容量 为 128MB ， 这 个 
值 一 般 来 说 是 偏 小 的 ， 因 此 从 Oracle 10g 开始 ， 子 池 的 最 小 容量 被 改 为 256MB ， 这 样 就 更 为 合 
RET, 而 在 118 版 本 中 , 子 池 的 最 小 值 又 扩大 了 一 倍 , 这 说 明 Oracle 也 已 经 认识 到 过 小 的 子 池 可 
能 导致 的 一 些 负面 影响 。 因 此 当 共 享 池 由 于 子 池 而 出 现 了 问题 的 时 候 ， 我 们 可 以 考虑 适当 减 小 
_kghdsidx_count 参数 的 值 ， 使 每 个 子 池 的 容量 大 于 256MB, ， 甚 至 S12MB 。 当 数据 库 经 常 出 现 碎 
片 而 导致 ORA-4031 错误 的 时 候 , 很 多 技术 文档 ,包括 Metalink 的 文章 都 建议 设置 kghdsidx count 
为 1， 即 关闭 子 池 功 能 。 事 实 上 ， 这 种 建议 可 能 会 矫 枉 过 正 ， 老 白 的 建议 是 适当 减少 ， 而 不 彻底 
关闭 。 如 果真 的 要 关闭 子 池 功能 , 那么 最 好 能 够 做 好 测试 ， 因 为 关闭 子 池 可 能 会 带 来 另外 一 个 问 
题 ， 那 就 是 共享 池 分 配 和 回收 又 变 成 囊 行 化 了 ， 这 种 情况 下 ,共享 池 门 锁 可 能 会 成 为 瓶 贷 ， 因 此 
这 种 调整 可 能 会 带 来 一 些 新 的 问题 。 


3.1.3 字典 缓存 


从 Oracle 堆 管 理 (KGH, HEAP MANAGEMENT ) 的 角度 来 看 ， 字 典 缓存 (Row Cache ) 是 
共享 池 的 一 个 子 堆 。 字 典 缓存 到 底 存 放 了 什么 信息 呢 ? 通过 下 面 这 个 简单 的 SQL , 我 们 来 看 看 字 
典 缓存 里 到 底 有 些 什么 内 容 。 


SQL> SELECT PARAMETER, SUM( COUNT) FROM V$ROWCACHE GROUP BY PARAMETER ORDER BY 
SUM( COUNT) ; 

extensible security principal na 
real m auth 

qmemod cache entries 

qmrc cache entries 
qmtmrctq cache entries 
qmtmrciq cache entries 
qmtmrctn cache entries 

AV row cache 3 

extensible security principal pa 
extensible security user and ro 
Rule Set Cache 
dc outlines 

kql subheap objec 
AV row cache 1 
extensible security midtier cach 
qmtmrcip cache entries 

qmtmrcin cache entries 
extensible security principal ne 
rule fast operators 

rule info 

dc qmc ldap cache entries 

qmc app cache entries 
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dc free extents 

dc tablespace quotas 

real m cache 

XS security class privilege 

rule or piece 

SMO rowcache 

Real m Subordinate Cache 

dc table scns 

Command rule cache 

extensible security UID to princ 

AV row cache 2 

qmtmrctp cache entries 

dc partition scns 

dc used extents 

prs errors 

Real m Object cache 

C 


dc profiles 
dc constraints 
outstanding alerts 
dc files 

sch lj objs 

dc sequences 

dc tablespaces 

dc object grants 12 
sch lj oi ds 16 
dc rollback segments 22 
dc global oids 30 
dc users 148 
dc segments 912 
dc objects 1625 
dc histogram defs 3329 
dc histogram data 4414 


上 面 的 结果 是 在 Oracle 11.2 数据 库 中 查询 得 到 的 ,在 9i 版 本 的 数据 库 中 结果 要 简单 得 多 ， 
下 面 的 结果 来 自 于 Oracle 9.2.0.8 数据 库 。 
PARAMETER SUM( COUNT 
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dc app role 
dc constraints 

dc database links 

dc encrypted objects 
dc encryption profiles 
dc files 
dc free extents 
dc outlines 
dc partition scns 

dc used extents 

dc tablespace quotas 

dc table scns 

dc qmc ldap cache entries 
dc qmc cache entries 

dc profiles 

dc sequences 
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dc tablespaces 3 
dc usernames 4 
dc user grants 5 
dc global oids 6 
dc users 8 
dc histogram data 9 
dc rollback segments 12 
dc histogram data val ues 44 
dc histogram defs 60 
dc segments 117 
dc objects 179 
dc object ids 195 


可 以 看 到 , 在 9i 版 本 的 数据 库 中 ， 字 典 缓存 包含 的 都 是 ас xxx 的 对 象 ， 我 们 知道 DC 是 
Dictionary Cache 的 缩写 ， 也 就 是 字典 缓冲 。 行 缓冲 (Row Cache ) 也 叫 字典 缓冲 ， 这 是 绝 大 多 数 
DBA 在 学 习 Oracle 时 就 能 学 到 的 知识 ， 而 且 很 多 培训 老师 也 会 告诉 你 字典 缓冲 为 什么 叫做 Row 
Cache， 因 为 缓冲 是 以 行为 单位 组 织 的 ， 这 里 要 区 别 于 DB Cache，DB Cache 是 以 块 (Block ) 为 
单位 的 。 有 些 知识 更 为 渊博 的 老师 还 会 告诉 你 ,数据 字典 的 缓冲 管理 和 普通 的 表 完全 不 同 , 字典 
缓冲 表 不 使 用 DB Cache， 而 使 用 字典 缓存 。 

这 个 知识 点 似乎 很 正确 ， 当 年 带 我 人 门 Oracle 的 老师 是 一 个 40 多 岁 的 香港 人 ， 已 经 是 这 个 
行业 的 资深 人 士 了 , 对 Oracle 原理 的 研究 也 比较 深 。 他 当时 就 是 这 么 教 我 的 , 我 也 理所当然 地 把 
这 个 知识 点 当成 真理 ， 又 传授 给 很 多 人 。 在 近 20 年 前 ， 几 乎 没有 这 方面 的 资料 ， 因 此 我 也 没有 
去 认真 地 求证 。 随 着 这 些 年 对 DB Cache 和 共享 池 研 究 的 深入 ， 我 终于 发 现 这 个 观点 是 错误 的 。 
字典 缓存 绝对 不 是 纯粹 的 数据 字典 表 的 缓冲 。 数 据 字 典 表 和 普通 的 表 没 有 不 同 , 其 数据 块 的 缓冲 
也 是 相同 的 。 而 字典 缓存 是 经 过 组 织 的 ， 用 于 数据 库 和 运行 中 SQL 解析 、 权 限 控 制 等 用 途 的 内 部 
数据 结构 ， 是 一 种 字典 表 的 内 存 视图 。 如 果 Oracle 在 执行 某 个 SQL 的 时 候 ， 为 了 SQL 解析 ， 需 
要 访问 一 些 字 典 表 ， 从 中 获取 一 些 数据 ， 那 么 它 会 通过 一 些 递归 调用 SQL 来 完成 这 些 事情 。 这 
些 SQL 和 普通 SQL 一 样 ， 需 要 将 数据 块 从 系统 表 空 间 中 读 取 到 DB Cache 中 ， 然 后 从 DB Cache 
中 获得 SQL 所 需要 的 行 数据 。 为 了 减少 递归 SQL 的 执行 开销 ， 这 些 行 数 据 被 缓存 在 共享 池 中 ， 
这 个 缓存 就 是 字典 缓存 。 

问题 似乎 明朗 化 了 , 字典 缓存 不 是 简单 的 数据 字典 表 的 缓冲 ,而 是 数据 字典 的 缓冲 。 从 更 本 
质 的 角度 讲 ， 字 上 典 缓存 其 实 是 一 种 Oracle 内 部 使 用 的 数据 结构 ， 是 基于 数据 字典 表 数 据 构 建 的 ， 
用 于 SQL 解析 等 操作 使 用 的 数据 结构 。 由 于 数据 字典 的 数据 十 分 庞大 ，Oracle 无 法 将 所 有 需要 
的 字典 信息 全 部 载 人 内 存 ， 因 此 对 字典 缓存 的 管理 也 采用 了 LRU 的 算法 。 字 典 缓存 中 保留 了 当 
期 活跃 的 数据 ， 一 些 不 常用 的 数据 将 会 被 置换 出 去 。 


3.1.4 ” 库 缓存 和 游标 


库 缓存 (library cache ) 也 是 共享 池 的 一 个 子 堆 。 和 行 缓存 相 比 ， 库 缓存 及 其 存放 的 数据 都 
更 为 复杂 。 在 分 析 库 缓存 的 内 部 结构 之 前 ,首先 要 了 解 一 下 库 缓 存 中 有 哪些 主要 的 对 象 。 库 缓存 
中 的 对 象 类 型 包括 Cursor, Table , Index , Cluster, View, Synonym, Sequence , Procedure , Function , 
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Package, Package Body, Trigger, Type, Type Body, Object, User, Database Link, Pipe, Table 
Partition, Index Partition, LOB, Library, Directory, Queue, Index-Organized Table, Java Source, 
Java Class, Java Resource, Java JAR Table Subpartition, Index Subpartition, LOB Partition, LOB 
Subpartition, Summary, Dimension, Stored Outline 等 。 

任何 一 个 对 象 类 型 肯定 属于 某 个 命名 空间 ( namespace )。 库 缓存 的 对 象 可 以 在 
V$DB_OBJECT_CACHE 中 找到 ,这 个 视图 基于 Oracle 内 部 结构 的 系统 视图 X$KGLOB。 下面 的 
结果 来 自 于 10.2.0.4 版 本 的 数据 库 。 


SQL>SELECT DISTINCT NAMESPACE FROM V$DB 0BJECT CACHE; 
AMESPACE 


SUBSCRI PTI ON 

TABLE/ PROCEDURE 

APP CONTEXT 

RSRC CONSUMER GROUP 
AVA RESOURCE 

AVA SHARED DATA 
TRI GGER 

AVA SOURCE 

RULESET 

CLUSTER 

NVALI D NAMESPACE 
BODY 


PVC Zu pe EAE. TEESE PER SD AR pha, РАА ak 
一 下 游标 的 基本 结构 。 一 个 游标 的 结构 包括 父 游 标 和 子 游标 ， 每 个 完整 的 游标 必须 包含 一 个 父 游 
bn, 并 且 至 少 包含 一 个 子 游标 ,我们 知道 每 个 SQL 都 对 应 相应 的 游标 。 但 是 在 一 个 大 型 的 系统 中 ， 
库 缓 存 可 能 有 几 千 兆 字 节 ，Oracle 如 何 快 速 地 找到 某 条 SQL 对 应 的 游标 呢 ? 遍历 整个 库 缓存 、 逐 
条 比 对 SQL 文本 肯定 不 是 一 个 好 方法 。Oracle 采用 了 十 分 简单 而 实用 的 方法 来 定位 游标 ,对 SQL 
的 文本 做 散 列 计算 ， 会 得 到 一 个 散 列 值 (HASH_VALUE )， 通 过 该 散 列 值 就 可 以 找到 相应 的 游标 
To 由 于 散 列 值 是 根据 游标 名 称 的 每 个 字符 进行 散 列 计算 得 到 的 (对 于 SQL 来 说 ， 游 标的 名 称 就 
是 SQL 文本 本 身 ), 而 ASCI 字 符 大 小 写 的 内 码 是 不 同 的 ,因此 select* from dual fll SELECT * FROM 
DUAL 这 两 条 语义 完全 相同 的 SQL 将 会 生成 不 同 的 散 列 值 ， 前 者 的 散 列 值 是 942515969， 而 后 者 
的 散 列 值 是 3991932091， 那 么 这 两 条 SQL 在 Oracle 数据 库 内 部 也 就 只 能 算是 不 同 的 语句 了 。 这 
也 是 以 前 我 们 常 说 的 编写 SQL 要 注意 大 小 写 及 空格 的 主要 原因 ， 相 关 示 例如 下 。 

SQL» select hash value,sql text from v$sql where UPPER(SQL TEXT) LIKE ' %FROM DUAL ， 


HASH_VALUE SQL TEXT 
3991932091 SELECT * FROM DUAL 
942515969 select * from dual 


3512519114 select * from dual 
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每 个 父 游标 包含 一 个 KGLHD 、 一 个 KGLOB .一 个 或 者 多 个 KGLNA。KGLOB 指向 子 堆 ( 每 
个 父 游标 至 少 包 含 一 个 Heap 0， 里 面 存放 环境 、 状 态 和 绑 定 变量 的 信息 )。KGLHD 是 每 个 游标 
的 入 口 ， 其 结构 如 代码 清单 3-3 所 示 。 


代码 清单 3-3 
struct kglhd { 
HASH Bucket 上 的 链接 指针 ; 
KIT FI RAGA; 
Lock 持 有 者 列表 指针 ; 
Lock 等 待 着 列表 指针 ; 
临时 锁 列 表 指 针 ; 
Pin 拥有 者 列表 指针 ; 
Pin 等 待 者 列表 指针 ; 
标识 ; 
Pin 实例 锁 状 态 ; 
等 待 释放 的 HANDLE 列表 指针 ; 
nvalidation 实例 锁 状 态 ; 
当前 锁 状 态 { KGLMO/ NI SI X) ; 
当前 PIN 状态 (KGLM0/ S/ X) ; 
库 缓 存 的 名 字 的 指针 (486) KGLNA) ; 
AMESPACE ID; 
489 kgl ob 的 指针 ; 
Load/reload 计数 ; 
nvalidation 计数 ; 
执行 次 数 计 数 ; 
Pin 临时 列表 ; 
FAB ID; 
具有 依赖 关系 的 handle 的 链表 指针 ; 
依赖 列表 指针 ; 
} 


上 面 的 KGLHD 结构 是 基于 Oracle 9; 的 ， 由 于 Oracle 在 游标 方面 的 优化 力度 很 大 ， 每 个 版 
本 在 性 能 上 都 有 质 的 提升 ， 因 此 各 个 版 本 中 这 个 结构 的 变化 也 很 大 。 不 过 其 主要 的 结构 仍然 不 
变 ， 我 们 还 是 可 以 从 9i 版 本 的 结构 中 看 出 一 些 开发 者 的 设计 思想 。KGLHD 结构 包含 了 游标 的 
一 些 最 为 基础 的 信息 ， 通 过 KGLHD 可 以 找到 和 这 个 游标 相关 的 所 有 的 关联 对 象 ， 并 且 游 标的 
一 些 统计 信息 也 包含 在 这 个 结构 中 。 在 KGLHD 中 ， 有 一 个 指向 KGLHD 的 指针 和 一 个 指向 
KGLNA 的 指针 ， 其 中 KGLNA 存放 的 是 这 个 库 缓 存 的 名 字 ( 对 于 SQL， 名 字 就 是 其 本 身 ， 对 
于 命名 的 PL/SQL 对 象 ， 名 字 就 是 库 缓存 的 名 字 )。KGLOB 则 存放 了 库 缓 存 的 对 象 信息 ， 其 结 
构 如 代码 清单 3-4 所 示 。 


代码 清单 3-4 
struct kglob ( /* 9201 struct kglob */ 
489 kgl hd 的 指针 ; 
当前 10ad lock 列表 指针 ; 
等 待 1 0ad lock 列表 指针 ; 
依赖 对 象 列 表 的 指针 ; 
当前 10ad lock 的 状态 (KGLM0O1X) ; 
FLAG; 
特殊 状态 ， 由 库 缓 存 门 锁 保 护 ; 
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本 状态 的 Bit Mask 定义 
1 // valid/ 无 授权 错误 
2 || valid/ 有 授权 错误 
3 || valid] 有 编译 错误 
4 J| valid/ 未 授权 
5 |] invalidl/ 未 授权 
6 ||] invalid] A4&4x e 4& | m [a] x 


KGLOB 的 类 型 
BitMask 

0 // cursor 

1 // index 


指针 指向 KGLOB SUBHEAP[ 16]; 
和 HEAP0 有 关 的 信息 区 域 的 指针 ; 
} 


每 个 KGLOB 包含 的 子 堆 可 能 的 情况 如 下 : 


Heap # Description 
0 Object 

Source 

DIANA 

PCODE 

MCODE 

Errors 

SQL Context 

Free 

Subordinate Heap 

Subordinate Heap 
0 Subordinate Heap 
1 Subordinate Heap 


кә кә «(oO co — CO» Un +. CO ко ка 


对 于 库 缓存 结构 的 描述 ，Julian Dyke 大 师 PPT 中 的 一 张 关 于 父 游标 的 结构 图 描述 得 很 清楚 , 
这 里 老 白 偷 个 懒 ， 引 用 一 下 大 师 的 图 示 ， 如 图 3-1 所 示 。 


KGLHD 


KGLOB KGLNA SELECT c1, 
c2,c3,c4,c5, 
c6,c7,c8,c9, 
c10 
KGLNA FROM 11,12, 
t3,t4,t5 
WHERE 
KGLNA t1.c1=t2.c1.. 
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看 了 上 面 老 白 描述 的 KGLHD 和 KGLOB 结构 ， 再 来 看 这 张 图 就 十 分 清晰 了 。 对 于 一 个 游标 
来 说 ， 父 游标 包含 句柄 ( KGLHD )、 对 象 结构 ( KGLOB ) 和 名 字 结 构 (KGLNA )。 每 个 父 游 标 
在 V$SQLAREA 中 有 一 条 记录 。 在 X$KGLOB 中 ，KGLHDPAR = KGLHDADR 的 记录 就 是 父 游 
标的 。 每 个 父 游标 至 少 有 一 个 子 游标 ， 子 游标 中 包含 : 环境 信息 、 统 计 信 息 、 绑 定 变量 、 执 行 计 
划 等 。 每 个 子 游标 包含 一 个 KGLHD、 一 个 KGLOB 和 SUBHEAP。 在 每 个 子 游标 中 ， 包 含 一 个 
Heap 6， 里 面 存放 的 是 执行 计划 。 

下 面 继续 引用 Julian Dyke 的 图 例 ， 如 图 3-2 所 示 。 


KGLHD a 
— = 

KGLOB KGLNA | 
+ 


[Smm 


KGLHD | | KGLHD | | KGLHD | | KGLHD | | KGLHD | | KGLHD 


图 3-2 


这 张 图 明确 地 显示 了 父 游标 和 子 游标 之 间 的 关系 。 父 游标 的 KGLOB 中 的 KGLDA 里 的 某 个 
列表 中 存放 了 子 游标 的 句柄 (KGLHD ) 指针 。 对 于 子 游标 的 结构 ，Dyke 也 有 一 张 很 棒 的 图 示 , 
如 图 3-3 所 示 。 


KGLHD | 
| 子 游标 
KGLOB 
环境 信息 统计 信息 绑 定 变量 执行 计划 
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我 们 看 到 Heap 0 中 包含 一 些 环境 信息 、 统 计 信 息 和 绑 定 变量 的 信息 ，Heap 6 中 包含 了 这 
SQL 的 执行 计划 。 

本 节 的 最 后 , 我 们 通过 一 个 实际 的 库 缓 存 转 储 来 验证 前 面 讨论 的 内 容 , 首先 看 一 下 父 游标 的 
转 储 信息 。 


LIBRARY OBJECT HANDLE: handle=7b9bc980 
name=SELECT abc,pos from Element WHERE pid=:1 and namespace=:2 order by pos 
hashz931b7ee9 timestamp=12-21-2011 19:19:06 
namespace=CRSR flags=RON/ KGHP/ TI M/ PNO/ MED/[50010000] 
kkkk-dddd- III! =0000- 0001-0001 lockzN pin=0 latch£zl 
| wt=0x7b9bc9b0[0x7b9bc9b0, 0x7b9bc9b0] Itm=0x7b9bc9co[0x7b9bc9c0,0x7b9bc9c0l] 
pwtz0x7b9bc9e0[0x7b9bc9e0,0x7b9bc9e0] ptmz0x7b9bca70[0x7b9bca70,0x7b9bca70 
refzüx7b9bc990[0x7b9bc990, 0x7b9bc990] Indz0x7b9bca88[0x7b9bca88, 0x7b9bca88] 
LIBRARY OBJECT: obj ect=7b9bc5a8 
type=CRSR flags=EXS[0001] pflags= [00] status=VALD | oad=0 
CHILDREN: size=16 
child# able reference handle 


0 7b9bc808 7b9c4e40 7b9c4c08 


LIBRARY OBJECT 的 HANDLE ( kglhd ) 的 地 址 是 7b9bc980， 名 字 就 是 SELECT 语句 本 身 。 
散 列 值 是 0x931b7ee9, LIBRARY OBJECT ( kglob ) 的 地 址 是 7b9bc5a8， 其 中 的 子 游标 列表 的 大 
小 是 16， 这 是 因为 KGLOB 数据 结构 中 定义 了 固定 大 小 的 列表 ， 因 此 如 果 列 表 中 数据 项 不 足 16 
会 占用 一 个 列表 ， 超过 16 个 会 级 联 多 个 列表 。 这 个 游标 只 有 一 个 子 游标 ， 其 KGLHD 的 地 址 是 
7b9c4c08， 通 过 该 地 址 我 们 找到 了 这 个 子 游标 : 


LIBRARY OBJECT HANDLE: handle=7b9c4c08 
namespace=CRSR flags=RON/ KGHP/ PN0/[10010000] 
КККК- 090-1111 =0000- 0041-0041 lockzN pin=0 latch#=1 
| wt z0x7b9c4c38[0x7b9c4c38,0x7b9c4c38] 1 т=0х709с4с48[ 0x7b9c4c48, 0x7b9c4c48 
pwtz0x7b9c4c68[0x7b9c4c68,0x7b9c4c68] ptm=0x7b9c4cf 8[ 0x7b9c4cf 8, 0x7b9c4cf 8] 
ref =0x7b9c4c18[0x7b9c4e40, 0x7b9c4e40] Indz0x7b9c4d10[0x7b9c4d10,0x7b9c4d10] 
LIBRARY OBJECT: obj ect =7b9c4830 
ype=CRSR flags=EXS[0001] pflags= [00] status=VALD | oad=0 
DEPENDENCIES: Count=l size=16 
ACCESSES: count=1 size=16 
TRANSLATIONS: count=1 size=16 
DATA BLOCKS: 


data# heap pointer status pins change 
0 7b9c4b48 7b9c4530 1/Р/А 0 NONE 
6 7b9c4950 7b9bcea8 I/-/A 0 NONE 


可 以 看 到 ， 这 个 子 游 标的 KGLOB 指向 了 两 个 子 堆 ，SUBHEAP0 和 SUBHEAP6， 一 个 存放 
环境 信息 ， 另 一 个 存放 执行 计划 。 


3.2 ”共享 池 和 游标 
游标 是 共享 池 中 最 为 重要 的 组 件 之 一 , 如 果 仅仅 讨论 共享 池 而 不 涉及 游标 , 那么 我 们 就 很 难 
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理解 共享 池 的 大 部 分 工作 原理 。 另 外 ， 优 化 共享 池 在 多 数 情况 下 就 是 优化 游标 并 发 访问 的 性 能 。 
本 方 主要 讨论 共享 池 和 游标 的 一 些 基 本 原理 。 


3.2.1 游标 与 游标 共享 


游标 共享 是 共享 池 的 重要 功能 之 一 ， 它 可 以 提高 共享 池 的 使 用 效率 , 减少 SQL 解析 的 开销 ， 
从 总 体 上 提高 SQL 执行 的 效率 。 如 果 一 条 SQL 能 够 被 解析 一 次 ， 执 行 多 次 ， 那 么 就 可 以 达到 比 
较 好 的 效果 ， 减 少 分 析 的 开销 ， 这 是 Oracle SQL 共享 的 最 高 目标 。 

要 实现 游标 共享 , 首先 要 具备 一 定 的 机 制 , 也 就 是 说 游标 的 一 些 执行 结构 不 能 存放 在 程序 的 
私有 空间 里 , 而 需要 存放 在 共享 内 存 中。 共享 池 中 的 库 缓存 就 是 实现 这 种 共享 机 制 的 载体 。 一 个 
可 共享 的 游标 ， 其 可 共享 的 部 件 是 存放 在 库 缓 存 中 的 ， 这 样 就 实现 了 不 同 SESSION 共享 同一 
SQL。 

满足 了 上 述 条 件 后 ， 下 一 步 就 要 来 判断 哪些 SQL 是 可 以 共享 的 。 最 简单 的 判断 方法 就 是 : 
SQL 语句 完全 相同 的 SQL 是 可 以 共享 的 。 如 何 来 判断 SQL 完全 相同 呢 ? 如 果 能 对 该 SQL 的 语义 
语法 进行 全 面 解析 , 通过 最 终 分 解 出 的 TOKEN 来 进行 比较 是 最 好 的 , 这 样 能 够 对 SQL 进行 全 面 
的 识别 。 但 是 这 种 识别 方式 的 开销 很 大 ，Oracle 采取 了 一 种 十 分 巧妙 的 方法 来 分 辨 不 同 的 SQL. 
通过 对 SQL 的 文本 进行 计算 ， 生 成 一 个 散 列 值 ， 如 果 散 列 值 不 同 ,那么 SQL 肯定 不 同 ; 如 果 散 
列 值 相同 ， 就 可 能 是 可 以 共享 的 SQL。 这 种 机 制 的 实现 十 分 简单 ， 比 较 相 同 SQL 的 开销 也 非常 
小 ,不 过 它 对 SQL 的 书写 要 求 较 高 ， 对 于 大 小 写 、 空 格 等 有 严格 的 要 求 ， 如 果 不 符合 要 求 ， 即 
使 语法 语义 完全 相同 的 SQL, Oracle 也 会 认为 是 不 同 的 。 
基于 上 述 原 理 ，Oracle 判断 游标 共享 的 第 一 个 原则 是 ， 可 共享 的 游标 的 SQL 文本 必须 完全 
相同 。 一 个 游标 在 执行 前 ， 首 先 对 其 文本 计算 散 列 值 ， 然 后 通过 该 散 列 值 在 HASH Bucket KÆ 
找 ， 如 果 找 到 了 相同 的 游标 ， 而 且 该 游标 的 所 有 对 象 (包括 SUBHEAP ) 都 是 可 用 的 (VALID ), 
那么 这 个 SQL 在 执行 的 时 候 ， 就 可 以 使 用 共享 的 游标 。 如 果 某 些 对 象 已 经 被 换 出 (AGEOUT ), 
那么 这 个 游标 就 需要 进行 软 分 析 ， 将 丢失 的 部 分 补充 完整 才能 执行 。 

如 果 两 条 SQL 的 文本 完全 相同 ， 是 不 是 就 一 定 能 够 共享 呢 ? 答案 是 否定 的 。 比 如 ，SCOTT 
All TIGER XXMA SCHEMA, 其 下 都 有 名 为 “TT” 的 表 。 如 果 在 这 两 个 用 户 下 都 执行 select 1 from 
tt where rownumx2， 则 两 条 SQL 所 访问 的 表 是 不 同 的 ， 因此 它们 是 不 应 该 共享 的 。Oracle 在 这 种 
情况 下 是 怎么 处 理 的 呢 ? 首 先 ， 由 于 SQL 文本 完全 相同 ， 所 以 这 两 条 SQL 具有 相同 的 SQL_ID 
和 散 列 值 ， 被 认为 是 相同 的 SQL， 在 V$SQLAREA 中 可 以 看 到 如 下 结 


SQL ID ADDRESS SQL TEXT VERSI ON. COUNT 
срј nybv7021rv 1F7059E0 select 1 from tt where rownum<2 2 


这 条 SQL 的 version count 是 2， 即 存在 两 个 子 游 标 。 接 下 来 我 们 在 V$SQL 中 看 到 如 下 结 
SQL ID ADDRESS SQL TEXT 


срј nybv7021rv 1F7059E0 select 1 from tt where rownum<2 
cpjnybv7021rv 1F7059E0 select 1 from tt where rownum<2 
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可 以 看 出 ,这 两 条 SQL 被 认为 是 相同 的 , 但 是 cpjnybv7021rv 包含 两 个 子 游 标 。 为 什么 会 产 


生 两 个 子 游标 呢 ? 通过 v$sql_shared_cursor 可 以 看 到 : 


SQL» select sql id,address,child address,child number,translation mismatch from 
2 v$sql shared cursor where sql_id='cpjnybv7021rv'; 


SQL ID ADDRESS CHILD AD CHILD NUMBER T 
cpjnybv7021rv 1F7059E0 23197488 0 N 
cpjnybv7021rv 1F7059E0 232BC270 1 Y 


不 难 发 现 ， 第 一 个 子 游标 在 这 个 视图 中 的 所 有 mismatch 都 是 N， 而 第 二 条 SQL H T 


translation mismatch 导致 不 能 共享 ， 其 原因 是 在 执行 translation 时 发 现 相 关 的 对 象 不 同 。 通 过 库 
绥 存 转 储 得 到 如 下 结果 (alter system set events 'immediate trace name library_cache level 10'; ): 


Bucket 67323: 
LIBRARY OBJECT HANDLE: handle=1f7059e0 mutex=1F705A94( 2) 
name=select 1 from tt where rownum«2 
hashz1cd693ce0a964189cac69e5ece0106fb ti mestampz12- 11-2007 16:18:05 
namespace=CRSR flags-RON/KGHP/ TI M/ KEP/ PNO/ SML/ KST/ DBN/ MTX/[120100d4] 
КККК- 0000-1111 =0001- 0001-0001 lockz0 pin=0 latch#=3 hpc=0000 hlcz0000 
| wt z1F705A3C[ 1F705A3C, 1F705A3C] | tm=1F705A44[1F705A44, 1Е705А44] 
pwt =1F705A20[ 1F705A20, 1F705A20] ptmz1F705A28[ 1F705A28, 1F705A28 
ref z1F705A5C[ 1F705A5C, 1F705A5C] Indz1F705468[232C803C, 1F705164] 
DEPENDENCY REFERENCES 
reference latch flags 
06b0c68 0 [60] 
20642c5c 0 [60] 
LIBRARY OBJECT: obj ect =206b138c 
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD | oad=0 
CHILDREN: size=16 
child# able reference handle 
0 206b1318 206b0fcc 231974b8 
1 20601318 206b112c 232bc270 


ко ' 


DATA BLOCKS: 
data# heap pointer status pins change whr 
0 2316d4bc 206b1424 I/P/A/-/- 0 NONE 00 


Bucket 67323 total object count=1 
从 TRACE 上 我 们 可 以 看 出 ， 这 个 父 游 标的 文本 就 是 select 1 from tt where rownum<2, C4, 


含 了 2 个 子 游标 ， 其 中 一 个 子 游标 的 句柄 (KGLHD ) 的 地 址 是 231974B8， 其 详细 信息 如 下 : 


LIBRARY OBJECT HANDLE: handle=231974b8 mutex=2319756C(0) 
namespace=CRSR flags=RON/ KGHP/ PNO/ [10010000] 
КККК- 090-1111 =0000- 0041-0041 lockz0 pin=0 latch#=3 hpc=0000 hl c=0000 
| wt =23197514[ 23197514, 23197514] | tm=2319751C[ 2319751C, 2319751C 
pwt =231974F8[231974F8, 231974Е8] ptm=23197500[ 23197500, 23197500 
ref z23197534[206B0FCC, 206B0FCC] | nd=23197540[ 23197540, 23197540] 
CHILD REFERENCES 
reference latch flags 


206b0f cc 0 CHL[ 02] 
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LIBRARY OBJECT: object=206b0b2c 
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD | oad=0 
DEPENDENCIES: count=1 size=16 
dependency# table reference handle position flags 

0 20759070 20758d70 230c63b8 14 DEP[ 01] 
READ ONLY DEPENDENCIES: countzl size=16 
dependency# table reference handle flags 

0 206b0ee8 206b0c68 1f7059e0 / ROD/ KPP[ 60) 
ACCESSES: Count=l size=16 
dependency# types 


0 0009 
TRANSLATIONS: count =1 size=16 
original final 


230c63b8 230c63b8 
DATA BLOCKS: 


datas heap pointer status pins change whr 
0 23202038 206b0c7c I/-/A/-/- 0 NONE 00 
6 20758ca4 201а185с 1/-/A/-/- 0 NONE 00 


这 个 子 游标 的 依赖 关系 列表 中 有 一 个 对 象 的 句柄 是 230c63b8 ， 我 们 再 来 看 看 230c63b8 对 应 
的 对 象 到 底 是 什么 。 


Bucket 99929 
LIBRARY OBJECT HANDLE: handlez230c63b8 mutex-230C646C( 0) 
name=SCOTT. TT 
hashzdcfddf221c9799c3b07c3d16af 408659 ti mestampz12- 11-2007 16:16:45 
namespace=TABL flags-KGHP/ TI М/ SML/[02000000] 
КККК- 090-1111 =0000- 0701-0701 lockzN pin=0 latch#=1 hpc=0002 hlcz0002 
| wt =230C06414[ 23006414, 23006414] 11 т=230С641С[230С641С, 230C641C 
рм -230C63F8[230C63F8,230C63F8] ptm=230C6400[ 23006400, 23006400 
ref =230C06434[ 23006434, 23006434] | nd=230C6440[ 23289660, 1F6575D8] 
DEPENDENCY REFERENCES 
reference latch flags 


20478ce0 2 DEP[ 01) 
20758d70 0 DEP[ 01) 
LOCK OWNERS: 

lock user session count mode flags 
20f 9e5e4 2373238c 23733654 ON [4000] 
20fc86cc 2373238c 2373238с ON [4000] 


LIBRARY OBJECT: obj ect =20758884 
type=TABL flags=EXS/LOC{[ 0005] pflags=[0000] status=VALD | oad=0 
DATA BLOCKS: 


data# heap pointer status pins change whr 
0 2324da64 2075891c 1/-/А/-/ 0 NONE 00 
8 20758aac 20607298 1/-/A/-/- 0 NONE 00 
9 20758b44 204cf62c I/-/Al-/- 0 NONE 00 
10 20758b94 2073e4e0 |/-/A/-/- 0 NONE 00 


Bucket 99929 total object count=1 
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从 名 称 上 可 以 看 出 这 个 对 象 是 表 SCOTT.TT， 再 来 看 看 第 二 个 子 游标 232bc270 的 信息 。 


LIBRARY OBJECT HANDLE: handlez232bc270 mut ex=232BC324(0) 
namespace=CRSR flagszRON/KGHP/ PN0/[10010000] 
kkkk-dddd-111120000-0041-0041 lockz0 pin=0 latchéz3 hpc=0000 hlcz0000 
| wt 2232BC2CC[232BC2CC, 232BC2CC] | tm=232BC2D4[ 232BC2D4, 232BC2D4] 
pwt =232BC2B0[232BC2B0, 232BC2B0] ptm=232BC2B8[ 232BC2B8, 232BC2B8] 
ref =232BC2EC[ 206B112C, 206B112C] | nd=232BC2F8[232BC2F8, 232BC2F 8] 
CHILD REFERENCES 
reference latch flags 
206b112c 0 CHL[ 02] 
LIBRARY OBJECT: obj ect =20642b20 
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD | oad=0 
DEPENDENCIES: countzl size=16 
dependency# table reference handle position flags 
0 2059d22c 2059cf2c 1f708c18 14 DEP[ 01] 
READ ONLY DEPENDENCIES: count =1 size=16 
dependency # table reference handle flags 


从 中 找 出 依赖 的 对 象 1708c18， 其 对 应 的 对 象 为 : 


Bucket 68671: 

LIBRARY OBJECT HANDLE: handlez1f708c18 mutex=1F708CCC( 0) 

name=T2. TT 

hashzb6efdd23a914ea2ealb8ffeb7d170c3f timestampz12-11-2007 16:16:15 

namespace=TABL flags-KGHP/ TI M SML/[02000000] 

КККК- 0900-1111 =0000- 0701-0701 lockzN pin=0 latch#=2 hpc=0002 hlcz0002 

| wt =1F708C74[1F708C74, 1F708C74] Itmz1F708C7C[ 1F708C7C, 1F708C7C 

pwt =1F708C58[1F708C58, 1F708C58] ptmz1F708C60[ 1F708C60,1F708C60 

ref =1F708C94[1F708C94, 1F708C94] Indz1F708CA0[ 1F705910, 1F708B48] 
DEPENDENCY REFERENCES 
reference latch flags 


20746154 2 DEP[ 01] 
2059cf 2c 0 DEP[ 01] 
LOCK OWNERS: 


lock user session count mode flags 
2125a5dc 2373491c 23733654 0 М [4000] 
212345d0 2373491c 2373491c ON [4000] 
LIBRARY OBJECT: obj ect =2059ca40 
type=TABL flags=EXS/LOC{[ 0005] pflags=[0000] status=VALD | oad=0 
DATA BLOCKS: 


data# heap pointer status pins change whr 
0 2324abc0 2059cad8 I/-/A/-/- 0 NONE 00 
8 2059cc68 2059c8fc I/-/Al-/- 0 NONE 00 
9 2059cd00 2059c10c I/-/A/-/- 0 NONE 00 
10 2059cd50 2059bd14 I/-/A/-/- 0 NONE 00 


Bucket 68671 total object count=1 
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这 个 对 象 是 T2.TT， 这 两 张 表 是 完全 不 同 的 ， 所 以 SQL 不 能 共享 。 除 了 这 种 情况 ， 还 有 哪 
些 不 可 共享 的 原因 呢 ? 从 v$sql_shared_cursor 的 字段 中 就 可 以 看 出 不 可 共享 的 各 种 原因 。 

另外 一 种 典型 的 SQL 不 能 共享 的 情况 是 两 个 SQL 的 执行 计划 不 同 。 如 果 两 个 SQL 相同 , 但 
是 由 于 参数 不 同 ， 必 须 使 用 不 同 的 执行 计划 ， 那 么 最 好 不 要 共享 这 种 SQL。 因 为 SQL 共享 带 来 
的 好 处 可 能 只 是 执行 了 错误 的 执行 计划 的 几 百 分 之 一 。 从 这 方面 来 看 ， 我 们 也 不 能 片面 地 强调 
SQL 共享 ， 而 忽略 了 由 于 SQL 共享 带 来 的 问题 。 
举 个 简单 的 例子 。TA 表 有 个 字段 是 STATUS ， 其 中 99% 的 值 都 是 END, RA 1% 的 字段 是 
BEGIN。 我 们 的 大 多 数 程序 都 是 每 次 读 取 值 为 BEGIN 的 行 ， 然 后 处 理 ， 处 理 结束 后 STATUS ЖЕ 
成 END。 只 有 少量 的 统计 操作 需要 统计 END 值 的 行 数 量 。 这 时 如 果 我 们 可 以 使 用 柱状 图 ,优化 
器 就 能 够 做 出 判断 并 使 用 合理 的 执行 计划 。 这 种 情况 下 , 不 能 使 用 绑 定 变量 。 如 果 使 用 了 绑 定 变 
E, 那么 对 于 早期 版 本 ,优化 器 就 不 会 使 用 柱状 图 ， 而 会 使 用 默认 的 选择 性 值 来 判断 ;如果 是 
9i 或 者 更 高 版 本 的 数据 库 , 绑 定 变量 寅 探 技 术 可 以 通过 使 用 柱状 图 来 选择 较 好 的 执行 计划 , 但 是 
它 只 在 SQL 第 一 次 被 执行 时 , 执行 硬 解 析 的 时 候 进 行 , 由 于 后 面 的 所 有 SQL 都 使 用 了 绑 定 变 量 ， 
会 被 认为 是 安全 的 ， 这 条 SQL 会 使 用 共享 的 游标 ， 因 此 就 不 会 进行 帘 探 。 这 条 SQL 可 能 有 两 种 
执行 计划 ， 索 引 扫 描 或 者 全 表 扫 描 ， 至 于 选择 哪 种 执行 计划 ， 则 完全 取决 于 执行 硬 解 析 的 那 条 
SQL 的 绑 定 变量 的 值 ， 而 无 法 由 优化 器 做 出 最 佳 的 选择 。 在 这 种 情况 下 ， 共 享 SQL 的 代价 就 太 
大 了 。 所 以 SQL 共享 是 优化 的 手段 ， 而 不 是 优化 的 目标 ， 千 万 不 能 为 了 优化 而 优化 。 对 于 不 同 
的 变量 值 ， 希 望 使 用 不 同 的 执行 计划 ， 如 果 选 错 了 执行 计划 ， 会 大 幅度 增加 SQL 的 开销 ， 那 么 
就 要 慎 用 绑 定 变量 了 。 这 个 时 候 可 能 不 使 用 绑 定 变量 对 系统 整体 性 能 的 改善 最 有 利 。 在 9i 版 本 
中 ， 默 认 情 况 下 表 分 析 是 不 采集 柱状 图 的 ， 而 在 10g 版 本 中 ， 柱 状 图 的 采集 是 默认 的 。 

不 过 10g 和 9; 的 绑 定 帘 探 技术 还 是 存在 一 定 的 局 限 性 。 对 于 使 用 了 绑 定 变 量 的 SQL ， 绑 定 
舌 探 往往 无 法 达到 较 好 效果 ,因此 Oracle 11g 引入 了 一 种 新 的 游标 共享 机 制 ACS( Adaptive Cursor 
Sharing， 自 适应 游标 共享 )， 首 先 引 入 ACS 的 稳定 版 本 是 11.1.0.6 ACS 在 共享 SQL 和 SQL 执 
行 时 的 资源 消耗 之 间 实 了 更 好 的 平衡 , 其 基本 思想 就 是 对 于 使 用 了 绑 定 变 量 的 SQL, 不 会 盲目 地 
使 用 一 个 共享 的 执行 计划 ,而 是 根据 其 绑 定 变量 值 的 选择 性 的 不 同 , 分 为 几 个 组 , 每 组 使 用 不 同 
的 执行 计划 。ACS 的 出 现 ， 使 绑 定 变量 的 使 用 没有 了 顾虑 ， 可 以 有 效 地 提高 此 类 SQL 的 效率 。 

但 是 , ACS 也 存在 一 些 副 作用 。 首先 由 于 每 次 SQL 执行 都 需要 分 析 绑 定 变 量 , 这 增加 了 SQL 
解析 的 开销 。 同 时 ， 它 也 加 大 了 游标 不 能 共享 的 机 会 ,增加 了 硬 解析 的 比例 。 另 外 一 个 游标 中 不 
能 共享 的 版 本 的 数量 也 会 大 大 增加 ， 这 样 就 影响 了 库 缓存 的 性 能 。 

另外 , 由 于 目前 ACS 还 算是 一 种 新 技术 ,肯定 存在 一 些 不 完善 的 地 方 ， 在 高 并 发 的 系统 中 ， 
也 可 能 会 出 现 一 些 Bug。 因 此 我 们 在 使 用 ACS 这 个 新 功能 的 时 候 ， 还 是 要 十 分 注意 ，ACS 可 能 
会 导致 一 个 父 游标 下 面 有 大 量 的 子 游标 无 法 共享 , 实际 上 这 些 游标 都 是 可 以 共享 的 。 如 果 碰 到 类 
似 的 情况 ， 那 么 就 必须 关闭 ACS， 使 用 10g 或 者 以 前 版 本 的 游标 共享 机 制 了 。 


3.2.2 ”游标 与 SQL 的 执行 
搞 清楚 SQL 执行 的 原理 一 直 是 绝 大 多 数 DBA 所 希望 的 , 这 些 年 来 老 白 也 一 直 在 做 这 方面 的 
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研究。 不 过 由 于 SQL 执行 涉及 太 多 Oracle 底层 的 原理 ， 而 且 关联 的 知识 点 十 分 广泛 ， 因 此 老 白 
也 仅仅 是 管 中 首 豹 ， 略 知 一 二 。 根 据 Oracle 官方 的 说 法 ，SQL 话 句 的 执行 有 以 下 步骤 : 
О Syntactic, 语法 检查 。 
口 Semantic， 确 认 所 有 对 象 都 存在 并 且 可 以 访问 。 
口 View Merging， 进 行 查询 重 写 优 化 。 
口 Statement Transformation, ， 将 复杂 的 查询 分 解 。 
口 Optimization， 确 定 访问 方式 ， 选 择优 化 策略 。 
О QEP Generation ， 形 成 执行 计划 。 
О QEP Ехесийоп, ， 运 行 执行 计划 。 

上 面 的 ОЕР 是 查询 执行 计划 的 英文 简称 。 在 这 七 个 步骤 中 ， 前 六 步 就 是 我 们 通常 所 说 的 解 
析 (PARSING )， 第 七 步 就 是 通常 所 说 的 执行 ( EXECUTION )。 正 如 前 面 几 节 所 述 ， 为 了 不 重复 
解析 相同 的 SQL 语句 ， 在 第 一 次 解析 之 后 ，Oracle 将 SQL 语句 存放 在 库 绥 存 中 。 这 块 位 于 系统 
全 局 区 域 SGA 的 共享 池 中 的 内 存 可 以 被 所 有 的 数据 库 会 话 共 享 。 因 此 , 一 条 SQL 语句 在 执行 时 ， 
如 果 和 之 前 执行 过 的 语句 完全 相同 ，Oracle 就 能 很 快 获得 已 经 被 解析 的 语句 以 及 最 好 的 执行 路 
径 。Oracle 的 这 个 功能 大 大 提高 了 SQL 的 执行 性 能 并 节省 了 内 存 的 使 用 。 表 3-1 更 加 详细 地 描述 
T SQL 的 执行 过 程 ( 表 3-1 AF Metalink 上 的 文档 ， 老 白 将 其 翻译 为 中 文 了 )。 


表 3-1 
SQL 匹配 ， 语 法 语义 检查 通过 对 库 缓 存 中 对 象 的 比 对 , 进行 匹配 
Query Transformation 对 子 查 询 、 视 图 等 进行 重新 组 合 和 SQL 
改写 
RBO—— 根 | CBO 判断 对 象 访问 的 开销 以 | 每 个 对 象 都 独立 计算 成 本 以 及 返回 的 
据 规则 制定 及 结果 集 的 大 小 结果 集 的 大 小 


PARSE | 执行 计划 CBO— 判断 不 | 连接 方式 和 连接 顺序 被 | 这 个 步骤 里 面包 含 了 SQL 执行 计划 的 


同 的 连接 顺序 的 | 通盘 考虑 ， 并 且 找 到 开 | 优化 

不 同 开销 销 最 小 的 连接 方式 

产生 执行 树 执行 树 被 生成 后 放 在 库 
缓存 里 ， 当 SQL 执 行 的 


时 候 ， 被 用 来 驱动 查询 


分 配 绑 定 变量 需要 的 内 存 空间 , 绑 定 变 
EXECUTE 量 的 值 实现 绑 定 。 使 用 上 一 步 产生 的 执 
行 计划 执行 SQL 

SELECT 操 作 比 普通 的 SQL 多 了 一 个 
FETCH 步 又 ， 在 这 个 步骤 中 ， 实 际 的 
FETCH DB BLOCK 的 访问 才 会 产生 。 在 这 个 阶 
段 ， 将 剔除 不 需要 的 数据 ,把 结果 放 人 入 
结果 集 ， 传 输 给 客户 端 


在 10046 Trace 里 可 以 很 清楚 地 看 到 这 些 SQL 执行 的 步骤 ,不 过 实际 上 SQL 执行 并 不 像 上 述 
那样 简单 明了 。 这 些 步骤 之 间 可 能 会 产生 交 义 和 重 毒 ， 且 部 分 操作 可 能 提前 或 滞后 。 比 如 ， 对 于 
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使 用 了 绑 定 变量 情况 下 的 绑 定 宕 探 ， 要 实现 宕 探 ， 分 析 中 的 优化 步骤 可 能 延 后 到 执行 阶段 进行 ， 
因为 只 有 在 执行 阶段 ， 绑 定 变 量 的 值 才 是 明确 的 。 

要 执行 一 条 SQL， 并 且 尽 可 能 使 用 共享 的 游标 ，Oracle 采用 如 图 3-4 所 示 的 判断 流程 (来 自 
Oracle 官方 的 说 明文 档 ) 来 共享 游标 。 


Cursor 是 否 打 开 


Cursor 是 否 在 session cache 


Hold_cursor=y 并 且 Cursor 在 


cache 


服务 器 


SQL 是 否 存在 


图 3-4 


不 同类 型 SQL 的 执行 步骤 也 有 所 不 同 。 比 如 ，INSERT 语句 中 就 没有 FETCH 这 个 步骤， 
FETCH 是 SELECT 语句 的 独 有 步骤 。 记 得 前 些 年 有 人 问 老 白 一 个 问题 ，SELECT 语句 执行 的 过 
程 中 ， 读 数据 块 、 从 中 查找 数据 是 在 EXECUTE 阶段 完成 的 ， 还 是 在 FETCH 阶段 完成 的 呢 ? 以 
老 白 做 应 用 架构 设计 的 经 验 来 说 ， 有 些 SQL 在 读 取 一 个 游标 的 时 候 ， 有 可 能 不 会 把 打开 的 游标 
从 头 到 尾 读 取 一 遍 ， 就 因为 某 种 原因 结束 了 读 取 ， 甚 至 关闭 游标 。 如 果 SQL 执行 过 程 中 ， 在 读 
取 之 前 就 已 经 遍历 了 所 有 的 数据 块 , 找 出 所 有 的 结果 数据 , 那么 就 会 造成 浪费 。 因 此 , 在 FETCH 
阶段 才 去 访问 数据 才 是 最 好 的 选择 。 

不 过 Oracle 公司 的 官方 资料 并 没有 这 方面 的 描述 ， 因 此 老 白 想 到 了 一 个 验证 这 个 观点 的 方 
法 。 首 先 我 们 创建 一 张 表 : 


SQL» create table scott.testb as select * from dba objects; 
Table created. 
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为 了 得 到 准确 的 数据 ， 需 要 重启 数据 库 。 重 启 之 后 ， 数 据 库 的 DB Cache 是 干净 的 ， 然 后 我 
们 执行 : 

Set pause on 

Select object id from scott.testb; 


使 用 set pause on 是 为 了 让 SQL*Plus 的 FETCH 操作 不 能 立即 完成 。 每 次 停顿 等 竺 屏幕 输入 
ШЇ, FETCH 操作 是 停止 的 。 然 后 在 另外 一 个 窗口 ， 查 询 V$BH 视图 ， 查 看 TCH 指标 的 变化 : 


SQL> COL OBJECT_NAME FORMAT A40 TRUNCATE; 
SQL» COL SUBCACHE FORMAT A10 TRUNCATE; 
SQL» Select decode(pd.bp id, 1, KEEP',2, RECYCLE',3,  DEFAULT' , 4, 
2 '2K SUBCACHE', 5, '4К SUBCACHE',6,'8K SUBCACHE', 7, 
'16K SUBCACHE', 8,' 32K SUBCACHE',  UNKNOWN') subcache, bh.object name 
object name,bh.blocks,tch from x$kcbwds ds, 
X$kcbwbpd pd, (select /*+ use hash(x) */ set ds, 
о. паме object name, count(*) BLOCKS,sum(tch) tch 
3 4 5 6 fromobj$ o, x$bh x where o.dataobj # = x. obj 
7 and x.state !=0 and o.owners ! =0 
group by set ds,o.name) bh where ds.set id »- pd.bp lo sid 
and ds.set id <= pd.bp hi sid and pd.bp size !- 0 and ds.addrz-bh.set ds 
order by subcache,object name; 


SUBCACHE ОВЈ ЕСТ NAME BLOCKS TCH 
DEFAULT — AQ$ QUEUES 2 2 
DEFAULT — AQ$ QUEUES CHECK 1 1 
DEFAULT — AQ$ QUEUE TABLES 1 1 
DEFAULT — AQ$ QUEUE TABLES PRI MARY 1 1 
DEFAULT — DEF$ AQCALL 1 1 
DEFAULT DEF$ AQERROR 1 1 
DEFAULT REPCAT$ REPPROP 1 1 
DEFAULT — SYS 10T TOP 10254 1 1 
DEFAULT — SYS 10T TOP 50155 1 1 
DEFAULT — TESTB 329 57 
DEFAULT — XDB$CONFIG 6 6 
DEFAULT | XDB$SCHEMA URL 1 1 


12 rows selected. 


SUBCACHE — OBJECT NAME BLOCKS TCH 
DEFAULT —— AQ$ QUEUES 2 2 
DEFAULT — AQ$ QUEUES CHECK 1 1 
DEFAULT — AQ$ QUEUE TABLES 1 1 
DEFAULT AQ$_ QUEUE TABLES PRI MARY 1 1 
DEFAULT — DEF$ AQCALL 1 1 
DEFAULT DEF$ AQERROR 1 1 
DEFAULT REPCAT$ REPPROP 1 1 
DEFAULT — SYS 10T TOP 10254 1 1 
DEFAULT — SYS IOT TOP 50155 1 1 
DEFAULT — TESTB 384 116 
DEFAULT — XDB$CONFIG 6 6 
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DEFAULT XDB$SCHEMA_URL 1 1 


12 rows selected. 


SQL» | 

SUBCACHE OB) ECT. NAME BLOCKS TCH 
DEFAULT AQ$ QUEUES 2 2 
DEFAULT AQ$ QUEUES CHECK 1 ] 
DEFAULT AQ$ QUEUE TABLES 

DEFAULT AQ$ QUEUE TABLES PRIMARY 

DEFAULT DEF$ AQCALL 

DEFAULT DEF$ AQERROR 

DEFAULT REPCAT$ REPPROP 

DEFAULT — SYS 10T TOP 10254 

DEFAULT SYS | OT TOP 50155 1 1 
DEFAULT TESTB 399 136 
DEFAULT XDB$CONFIG 6 6 
DEFAULT XDB$SCHEMA_ URL 1 1 


12 rows selected. 

可 以 看 出 ， 随 着 读 取 的 进行 ， 载 入 内 存 的 BLOCKS 和 TCH 都 在 增长 。 而 未 执行 读 取 数 据 操 
作 时 ， 这 些 数据 都 是 静止 不 动 的。 这 个 例子 只 能 证 明 数 据 是 随 着 读 取 的 进行 而 被 访问 的 ， 那 么 
Oracle 是 否 存在 一 些 预 读 取 之 类 的 行为 呢 ? 答案 是 肯定 的 ， 为 了 提高 读 取 数 据 的 效率 ，Oracle 提 
供 了 预 读 取 功 能 。 通 过 下 面 几 个 参数 可 以 控制 预 读 取 的 行为 。 

.db block prefetch limit 


.db block prefetch quota 
.table lookup prefetch size 


Жоп, db block prefetch limit Ж1 db block prefetch quota 控制 数据 块 预 读 的 数量 ; 
table lookup. prefetch size 控制 数据 行 预 读 的 数量 ， 这 个 参数 的 默认 值 在 8.0 版 本 中 为 10，9%i 及 
后 续 版 本 中 被 加 大 为 40。 对 于 大 量 读 取 数 据 的 操作 ， 我 们 一 般 以 BULK COLLECT 的 方式 来 批 
量 处 理 ， 从 而 提高 读 取 的 性 能 。 此 外 ，BULK COLLECT 配 以 合适 的 _table_lookup_prefetch_size 
参数 值 也 可 以 提高 读 取 的 性 能 。 不 过 由 于 _table_lookup_prefetch_size 参数 不 能 做 会 话 级 调整 ， 因 
此 这 个 参数 的 调整 要 十 分 慎重 , 一 旦 调整 得 不 合理 将 会 影响 系统 的 性 能 。 如 果 调 整 幅度 太 大 , 可 
能 会 由 于 过 量 的 预 读 取 而 增加 不 必要 的 开销 。 

在 SQL 的 执行 过 程 中 ， 如 果 这 个 游标 是 开放 的 ,那么 SQL 的 执行 分 析 开 销 最 小 ， 不 需要 做 
任何 解析 ， 就 可 以 直接 执行 了 ， 这 种 情况 下 没有 解析 产生 。 如 果 执 行 的 游标 在 SESSION CACHE 
H, 虽然 还 是 统计 了 一 次 软 解析 , 但 是 和 一 般 的 软 解析 不 同 ,， 它 的 开销 很 小 ，Tom 称 之 为 软 软 解 
Br (soft soft parse )， 就 是 用 以 区 别 于 普通 的 软 解析 。 

其 实 解析 的 过 程 是 十 分 复杂 的 ， 绝 对 不 是 硬 解 析 (hard parse )、 软 解析 (soft parse) 和 软 软 
解析 (soft soft parse) 这 三 种 方式 就 可 以 概括 的 。 比 如 ， 执 行 一 条 SQL 的 时 候 ， 如 果 该 SQL 在 
共享 池 中 不 存在 ， 那 么 很 简单 ， 这 就 是 硬 解析 ， 需 要 首先 分 配 共 享 池 空间 ,创建 父 游标 的 结构 ， 
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然后 创建 一 个 子 游标 。 如 果 下 一 次 再 执行 一 条 类 似 的 SQL, 1X SQL 的 父 游标 存在 ， 经 过 检查 发 
现 子 游标 是 可 以 共享 的 , 而 且 这 个 子 游标 的 所 有 关联 对 象 在 共享 池 中 都 存在 , 那么 就 可 以 马上 执 
行 了 。 这 就 是 我 们 所 说 的 软 软 解析 ， 其实 这 也 是 软 解析 的 一 种 。 还 有 一 种 情况 ,如 果子 游标 是 不 
可 共享 的 , 那么 我 们 就 需要 创建 一 个 新 的 子 游标 (对 于 SQL 来 说 , 又 增加 了 一 个 版 本 ,Version ), 
解析 执行 计划 , 然后 执行 。 这 也 被 记录 为 一 次 软 解析 , 它 的 开销 明显 比 刚才 的 软 软 解析 高 出 很 多 。 
其 实 我 们 还 经 常 碰 到 另外 一 种 情况 ， 当 我 们 找到 某 个 子 游标 的 时 候 , 发 现 该 游标 相关 的 关联 对 象 
的 数据 不 完整 ,那么 就 必须 重新 生成 这 个 子 游标 才能 够 执行 SQL, 这 也 是 一 种 软 解析 。 为 什么 某 
个 子 游标 会 不 完整 呢 ? 共享 池 是 一 种 采用 LRU 机 制 的 共享 缓冲 , 当 共 享 池 空闲 空间 不 足 的 时 候 ， 
就 会 换 出 某 些 对 象 ， 从 而 腾 出 新 的 空间 给 需要 的 会 话 。 共 享 池 在 释放 内 存 的 时 候 ， 首先 释放 那些 
没有 上 锁 的 对 象 , 如 果 所 有 没 上 锁 的 对 象 都 被 释放 了 , 空间 还 是 不 足 , 才 会 释放 带 有 空 锁 的 对 象 ， 
而 被 锁 住 的 对 象 是 不 能 释放 的 。 

从 SQL 执行 的 原理 来 看 ， 尽 可 能 减少 硬 解 析 ， 其 至 减少 软 解析 都 可 能 给 系统 之 来 性 能 的 提 
升 。 要 想 减 少 硬 解 析 和 软 解析 ， 就 要 让 SQL 能 够 尽 可 能 地 在 共享 池 中 多 保存 一 段 时 间 ， 并 且 那 
些 执行 十 分 频繁 的 SQL 要 尽 可 能 保存 在 共享 池 中 。 保 持 共 享 池 有 足够 的 空间 存放 这 些 对 象 是 十 
分 重要 的 ， 因 此 在 共享 内 存 自动 管理 的 情况 下 ， 当 Buffer Cache 能 够 保持 足够 高 的 命中 率 时 ， 
Oracle 总 是 尽 可 能 地 扩展 共享 池 ， 这 样 也 导致 了 共享 池 十 分 庞大 。 

适当 保持 足够 大 的 共享 池 对 于 OLTP 系统 来 说 是 十 分 重要 的 。 只 有 共享 池 足 够 大 了 , 才能 够 
让 游标 的 所 有 相关 数据 尽 可 能 多 地 保存 在 共享 池 中 不 被 换 出 。 实际 上 , 一 套 应 用 系统 需要 配置 多 
大 的 共享 池 ， 和 应 用 的 总 体 架构 以 及 应 用 系统 的 特点 是 息息相关 的 。 对 于 一 些 负 载 十 分 高 、 每 秒 
事务 处 理 数量 达到 1000 左右 的 系统 来 说 ,可 能 5GB 左右 的 共享 池 就 足够 了 ， 而 对 于 另外 一 套 并 
发 处 理 量 小 10 倍 、 每 秒 事务 数 不 超过 20 个 的 系统 来 说 ， 可 能 SGB 共享 池 还 经 常 出 现 严重 的 争 
用 。 因 此 我 们 在 分 配 共 享 池 容 量 的 时 候 , 一 定 要 从 实际 应 用 系统 出 发 ， 绝 对 不 能 带 着 有 色 眼 镜 看 
问题 。 

在 互联 网 上 还 存在 着 一 个 观点 ， 就 是 共享 池 不 宜 过 大 , 过 大 的 共享 池 反 而 会 影响 性 能 。 这 个 
观点 看 似 有 点 道理 ， 因 为 如 果 共 享 池 太 大 ,搜索 对 象 所 需要 的 时 间 也 会 增加 , 这 就 存在 降低 性 能 
的 可 能 性 。 不 过 反 过 来 想 想 , 这 种 观点 似乎 也 站 不 住 脚 。 对 于 某 个 确定 的 Oracle 版 本 来 说 , 各 种 
Hash 链 的 Bucket 数量 是 固定 的 , 搜索 某 个 对 象 的 速度 取决 于 串 在 Hash 链 上 的 对 象 的 数量 , 如 果 
加 大 了 共享 池 , 导致 大 量 的 共享 池 空 间 是 没有 使 用 的 , 那么 这 些 空 闪 的 内 存 并 不 会 增加 搜索 共享 
池 对 象 的 开销 。 如 果 由 于 增加 了 共享 池 的 内 存 ， 导 致 更 多 的 共享 池 对 象 被 放 人 共享 池 中 , 从 而 使 
Hash 链 变 长 ， 这 确实 可 能 增加 检索 Hash 链 的 开销 。 但 是 和 不 停 地 释放 共享 池 、 分 配 共享 池 所 产 
生 的 开销 相 比 ， 这 些 开 销 可 能 小 很 多 了 。 因 此 共享 池 分 配 多 少 合适 ,并 不 是 一 个 简单 的 问题 ， 需 
要 和 应 用 特点 相 结合 去 分 析 ,， 有 时 候 确 实 需要 经 过 一 段 时 间 的 验证 才能 够 得 到 合理 的 答案 。 幸 运 
的 是 ， 从 9i 版 本 开始 ， 我 们 可 以 动态 分 配 共享 池 空间 ， 不 需要 因 修改 共 享 池 参数 而 重启 数据 库 
实例 了 。 

这 并 不 是 说 可 以 无 限制 地 配置 共享 池 。 共享 池 配 置 还 是 以 适当 为 好 , 过 大 的 共享 池 实 际 上 对 
提高 并 发 访问 性 能 没什么 益处 , 反而 会 由 于 堆 管 理 成 本 增加 而 导致 共享 池 性 能 略 有 下 降 。 加 大 共 
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享 池 不 是 万 应 良药 , 在 大 多 数 情况 下 , 共享 池 的 冲突 和 游标 相关 的 参数 设置 与 应 用 程序 未 合理 使 
用 绑 定 变量 有 关 ， 从 源头 上 解决 问题 才 是 最 佳 的 。 


3.2.3 游标 共享 和 绑 定 变量 


从 前 面 的 讨论 我 们 已 经 了 解 了 SQL 共享 的 重要 性 。SQL 共享 可 以 提高 共享 池 的 效率 ， 减 少 
SQL 的 解析 成 本 。 而 实现 SQL 共享 最 好 的 技术 就 是 使 用 绑 定 变量 ， 使 SQL 代码 一 致 ， 从 而 减少 
解析 带 来 的 开销 。 

不 过 绑 定 变量 是 让 人 爱 恨 交 加 的 技术 。 在 CBO 优化 器 功能 不 是 很 强 的 年 代 ， 很 多 系统 采用 
rule 提示 来 强制 使 用 RBO 优化 锅 ， 在 这 种 情况 下 绑 定 变量 的 缺点 还 没有 那么 明显 ， 大 不 了 不 用 
CBO 优化 器 罢了 。 但 在 Oracle 8i 或 者 以 前 的 版 本 中 ,对 于 绑 定 变量 的 CBO 执行 计划 的 产生 采用 
固定 的 方式 ， 因 此 对 于 那些 不 均匀 列 上 面 的 条 件 ， 产 生 的 估算 结果 往往 准确 性 欠 佳 。 

正 是 因为 这 个 原因 ，Oracle 9i 才 引 入 了 绑 定 变量 客 探 技术 (Bind Value Peeking ， 我 印象 中 是 
9.2， 不 知道 是 否 确切 )。 在 没有 这 项 技术 之 前 ， 使 用 绑 定 变量 后 ， 执 行 计划 的 产生 要 靠 默认 的 选 
择 性 判断 ， 这 种 判断 往往 会 出 现 严 重 的 偏差 。 加 了 这 项 技术 后 ， 当 SQL 进行 硬 解 析 的 时 候 ， 对 
于 使 用 了 绑 定 变量 的 字段 , 不 再 采用 以 往 默认 的 COST 来 分 析 的 方式 ,而 是 会 对 绑 定 变量 进行 窥 
探 ， 也 就 是 优化 器 采集 绑 定 变量 的 值 ， 用 窥探 到 的 绑 定 变量 的 值 来 计算 CBO 的 开销 ， 生 成 执行 
计划 。 下 面 的 示例 可 以 说 明 绑 定 变量 赛 探 技术 的 工作 原理 。 

SQL> var a number 

SQL» exec :а: =10; 

PL/SQL 过 程 已 成 功 完成 。 


SQL» select * from dept where deptno=:a 
DEPTNO DNAME LOC 
10 ACCOUNTI NG NEW YORK 
SQL» SELECT * FROM TABLE(DBMS XPLAN. DISPLAY CURSOR(NULL, NULL, 'ADVANCED']); 
---- ADVANCED X Oracle 内 部 使 用 的 未 正式 发 布 的 参数 
PLAN_TABLE_OUTPUT 


SQL ID 6a2y9jbwu5fz9, child number 0 


select * from dept where deptno=:a 
Plan hash value: 2852011669 


| Id | Operation | Na me | Rows |Bytes |Cost (%CPU) [Ті те | 
| 0 | SELECT STATEMENT | | | | 1 (100) | | 
| 1 | TABLE ACCESS BY INDEX ROMD | DEPT | 1 | 20 | 1 (0) |00:00:01| 
|* 2 | INDEX UNIQUE SCAN |PK DEPT | 1 | | 0 (0) | | 


1 - SEL$1 / DEPTQSEL$1 
2 - SEL$1 / DEPT@SEL$1 
PLAN TABLE OUTPUT 
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Outline Data 
[+ 
BEGIN OUTLINE DATA 
| GNORE OPTIM EMBEDDED HI NTS 
OPTI МІ ZER_ FEATURES ENABLE('10.2.0.1') 
ALL_ ROWS 
OUTLINE LEAF(Q'SEL$1") 
| NDEX(Q'SELS$1" "DEPT"@'SEL$1" ("DEPT". "DEPTNO")) 
PLAN TABLE OUTPUT 
END OUTLI NE DATA 
+] 
Peeked Binds (identified by position): 


1 - :A (NUMBER): 10 asaan 从 这 里 可 以 看 出 A: =10 被 用 来 PARSE 3x 4- SQL 
Predicate Information (identified by operation id): 


2 - access("DEPTNO"=:A) 


Column Projection Information (identified by operation id): 


1 - "'DEPTNO'[NUMBER,22], "DEPT'."DNAME"[ VARCHAR2, 14] 
"DEPT". "LOC" [ VARCHAR2, 13] 
2 - "DEPT". ROW D[ ROW D, 10], "DEPTNO"[ NUMBER, 22] 
已 选择 50 £T, 
SQL» exec :а: =20, ------- 看 看 A: =20 后 会 发 生 什么 
PL/SQL 过 程 已 成 功 完成 。 
SQL» select * from dept where deptno=:a 
DEPTNO DNAME LOC 
20 RESEARCH DALLAS 
SQL» SELECT * FROM TABLE(DBMS XPLAN. DISPLAY CURSOR(NULL, NULL, 'ADVANCED']); 


SQL ID 6a2y9jbwu5fz9, child number 0 


select * from dept where deptno=:a 
Plan hash value: 2852011669 


| Id | Operation | Name | Rows |Bytes |Cost (%CPU) | Ti me | 
| 0 | SELECT STATEMENT | | | | 1 (100) | 

| 1 | TABLE ACCESS BY INDEX ROWD| DEPT | 1 | 20 | 1 (0) | 00:00:01] 
|* 2 | INDEX UNI QUE SCAN [PK DEPT | 1 | | 0 (0) | | 


1 - SEL$1 | DEPT@SEL$1 
2 - SEL$1 / DEPT@SEL$1 


AE 


# 3 


E 
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PLAN TABLE OUTPUT 


OUTLINE DATA 

| GNORE OPTIM EMBEDDED HI NTS 

IZER FEATURES ENABLE('10.2.0.1') 
_ ROWS 
NE LEAF(Q'SELS$1") 

| NDEX(QG'SEL$1" "DEPT'Q'SEL$1" 
PLAN TABLE OUTPUT 


( "DEPT", "DEPTNO") ) 


NE DATA 
*[ 


identified by position): 


1 - :A (NUMBER): 10 peeked binds 的 值 并 没有 改变 ， 还 是 那个 值 。 
Predicate Information (identified by operation id): 


2 - access("DEPTNO" =: A) 
Projection Information (identified by operation id): 


1 - "DEPTNO"[ NUMBER, 22], "DEPT". "DNAME"[ VARCHAR2, 14] 
"DEPT". "LOC" [ VARCHAR2, 13] 
2 - "DEPT". ROW D[ ROW D, 10], "DEPTNO"[{ NUMBER, 22] 
已 选择 50 行 。 
SQL> spool off 


如 果 刷 新 一 下 共享 池 ， 会 出 现 什么 结果 呢 ? 


SQL» ALTER SYSTEM FLUSH SHARED POOL 


系统 已 更 改 。 


SQL» exec :a: =20 
SQL» select * from 
DEPTNO DNAME 


PL/SQL 过 程 已 成 功 完成 。 
dept where deptno=:a; 
LOC 


20 RESEARCH 


DALLAS 


SQL» SELECT * FROM TABLE( DBMS XPLAN. DISPLAY CURSOR(NULL, NULL, '‘ADVANCED')); 
PLAN TABLE OUTPUT 
SQL ID 6a2y9jbwu5fz9, child number 0 


select * from dept where deptno=:a 


Plan hash value: 2852011669 

|14] Operation | Name |Rows | Bytes |Cost (%CPU) | Ti me | 
[0 | SELECT STATEMENT | | | | 11100 

|1 | TABLE ACCESS BY INDEX ROMD|DEPT | 1 | 20 | 1 (0) | 00:00:01 | 
|*2| INDEX UNI QUE SCAN [PK DEPT| 1 | | 0 (0) | 
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1 - SEL$1 / DEPT@SEL$1 
2 - SEL$1 / DEPT@SEL$1 
PLAN TABLE OUTPUT 


BEGIN OUTLINE DATA 

| GNORE_ OPTIM EMBEDDED HI NTS 

OPTI MI ZER FEATURES ENABLE(' 10.2.0. 1') 

ALL ROWS 

OUTLINE LEAF(Q'SEL$1") 

DEX(Q'SEL$1" "DEPT'Q'SELS1" ("DEPT". "DEPTNO") 
PLAN TABLE OUTPUT 


END OUTLINE DATA 


у 
Peeked Binds (identified by position): 
1 - :A (NUMBER): 20 
LLL BIND PEEK 的 值 改变 了 。 说 明 重 新 分 析 的 时 候 会 重新 做 BI ND PE 
Predicate Information (identified by operation id): 


2 - access("DEPTNO"=: A) 
Column Projection Information (identified by operation id): 
1 - 'DEPTNO'[NUMBER,22], "DEPT". "DNAME"[ VARCHAR2, 14] 
"DEPT". "LOC" [ VARCHAR2, 13] 
2 - "DEPT". ROW DL ROW D, 10], "DEPTNO"[ NUMBER, 22] 
已 选择 50 fr, 


EKI NG 


通过 该 示例 , 我 们 可 以 看 出 绑 定 额 探 是 如 何 进行 的 。 当 硬 解 析 发 生 的 时 候 ， 绑 定 变量 窥探 就 
会 进行 。 一 旦 理解 了 这 个 原理 ， 就 不 难 明日 一 些 以 前 经 常 被 认为 是 “灵异 事件 ”的 现象 。 
第 一 个 “灵异 现象 ”是 ， 某 条 SQL 一 直 执行 得 很 正常 ， 突 然 就 变 得 特别 慢 了 。 碰 到 这 类 问 


题 如 何 分 析 呢 ? 首先 我 们 要 看 看 系统 资源 是 否 存在 瓶颈 , 是否 存 在 一 些 异常 的 问题 ， 比 如 出 现 换 
Ji. CPU 资源 不 足 、IO 问题 等 。 这 些 需 要 通过 操作 系统 的 监控 工具 进行 分 析 。 
如 果 分 析 发 现 系统 资源 情况 是 正常 的 , 下 一 步 就 需要 查看 系统 的 主要 等 待 事件 是 否 正常 , 是 


否 存 在 一 些 特殊 的 情况 。 这 个 可 以 通过 下 面 的 SQL 来 分 析 : 
Select count(*),event from v$session wait group by event order 


如 果 上 面 的 SQL 发 现 了 一 些 异 常 , 那么 就 要 具体 分 析 这 些 异 常 ， 看 看 


by count(*); 


这 些 等 待 和 什么 相关 。 


这 个 分 析 过 程 不 是 本 节 讨 论 的 重点 ,因此 我 们 不 再 深入 探讨 。 如 果 从 等 待 引 


和 件 上 没有 发 现 什 么 特 
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殊 的 情况 或 者 发 现 可 能 是 某 些 SQL 性 能 不 佳 导 致 ， 那 么 就 需要 进一步 分 析 SQL 的 问题 了 。 接 下 
来 ， 我 们 可 以 检查 SQL 的 执行 计划 ， 看 看 执行 计划 是 否 合理 。 对 于 一 些 较为 简单 的 SQL， 可 以 
很 容易 地 发 现 执行 计划 中 可 能 存在 的 问题 ,而 如 果 执 行 计划 十 分 复杂 ， 有 十 多 行 甚至 几 十 行 , 那 
么 分 析 执 行 计 划 的 最 佳 方法 就 是 保存 一 部 分 这 些 SQL 的 基线 ， 为 这 些 关键 SQL 的 正常 执行 计划 
建立 一 个 档案 库 。 通 过 和 历史 数据 的 比 对 来 发 现 问题 是 最 准确 和 快捷 的 。 

经 过 上 面 的 分 析 ， 我 们 可 能 会 发 现 某 个 使 用 绑 定 变量 的 SQL 的 执行 计划 突然 发 生 了 变化 ， 
变化 后 的 执行 计划 明显 是 不 合理 的 , 正 是 这 个 原因 导致 了 故障 的 发 生 。 既 然 问题 已 经 找到 了 ,， 比 
较 喜 欢 较真 的 朋友 可 能 会 有 些 疑 问 ， 为 什么 正常 的 SQL 的 执行 计划 就 发 生 了 改变 呢 ? 如 果 排 除 
了 相关 表 的 数据 发 生 较 大 变化 的 可 能 性 ， 那 么 执行 计划 改变 的 主要 原因 就 可 能 是 绑 定 变量 舌 探 。 
由 于 绑 定 变量 掺 探 只 在 人 硬 解析 发 生 的 时 候 进行 , 根据 这 一 点 就 可 以 推测 可 能 出 现 的 场景 。 由 于 共 
享 池 空闲 空间 比较 少 ， 所 以 部 分 共享 池 的 可 重用 的 对 象 被 刷 出 了 ， 其 中 正好 包含 了 这 条 SQL 的 
一 部 分 。 因 此 在 下 一 次 执行 该 SQL 的 时 候 ， 就 出 现 了 SQL 突然 变 慢 的 现象 。 这 时 绑 定 变量 的 值 
比较 特殊 , 从 而 导致 了 生成 的 执行 计划 和 以 往 的 不 同 。 如 果 再 深入 分 析 这 条 SQL, 我 们 就 会 发 现 ， 
绑 定 变量 对 应 的 字段 的 数据 不 是 均匀 分 布 的 ， 而 是 倾斜 的 ， 某 些 取 值 的 数据 量 比 较 大 ， 而 另 一 些 
取 值 的 数据 量 又 比较 小 。 

另外 一 个 “灵异 现象 ” 是, ТЕ КАС 的 不 同 节点 上 ， 相 同 的 两 个 SQL 的 执行 计划 不 同 。 如 果 

发 现 这 条 SQL 中 使 用 了 绑 定 变量 ， 并 且 绑 定 变 量 对 应 的 字段 的 值 域 也 是 倾斜 的 ， 那 么 绑 定 变量 
突 探 导致 这 个 问题 的 可 能 性 就 十 分 高 了 。 这 是 因为 КАС 的 多 个 实例 维护 自己 独立 的 共享 池 ， 一 
条 SQL 在 多 个 实例 上 执行 ， 必 须 分 别 解析 ， 在 КАС 环境 下 ，SQL 的 执行 计划 是 实例 范围 内 的 ， 
不 会 跨 实例 。 如 果 两 个 实例 在 解析 这 条 SQL 的 时 候 ， 突 探 到 的 绑 定 变量 的 值 是 不 同 的 ， 那 么 就 
可 能 导致 生成 的 执行 计划 也 不 同 。 
碰 到 这 样 的 问题 如 何 解决 呢 ? 可 能 大 家 首先 想到 的 是 刷新 共享 地, 确实, 刷新 共享 池 可 能 将 
某 个 SQL 的 游标 刷 出 ， 不 过 如 果 这 个 游标 被 锁 住 了 ， 那 么 刷新 共享 池 是 无 效 的 。 而 且 在 业务 高 
峰 期 进行 此 操作 也 存在 一 定 的 风险 ,共享 池 有 可 能 会 被 挂 起 ， 因 此 不 建议 采用 这 种 方式 。 要 解决 
好 这 个 问题 ， 就 需要 了 解 什么 情况 会 导致 SQL 被 重新 解析 。 已 知 的 情形 很 多 ， 比 如 ， 相 关 的 表 
和 索引 出 现 了 变更 ,相关 的 表 的 权限 发 生 了 变更 , 表 和 索引 的 统计 数据 发 生 了 变更 等 ， 都 能 够 导 
BEA SQL 被 重新 硬 解析 。 因 此 我 们 一 般 采 用 对 相关 表 授 权 的 方式 来 让 SQL 重新 解析 。 还 有 一 
个 更 为 安全 的 方法 ， 就 是 先 将 该 表 的 统计 数据 导出 ,然后 再 导入 , 这样 表 的 统计 数据 就 会 发 生变 
化 ， 从 而 导致 游标 被 重新 硬 解 析 。 

正 是 由 于 绑 定 变量 帘 探 的 局 限 性 ，Oracle 11g 推出 了 一 种 新 的 游标 共享 技术 ACS (Adaptive 
Cursor Sharing， 自 适应 游标 共享 ), 使 绑 定 变量 的 舌 探 技术 有 所 改变 。 每 次 绑 定 变量 都 会 被 舌 视 ， 
不 过 并 不 是 每 次 帘 视 都 会 产生 新 的 执行 计划 ， 一 旦 发 现 某 个 绑 定 变量 取 值 和 已 有 的 值 域 有 所 不 
同 ， 就 会 产生 新 的 子 游标 ， 生 成 新 的 执行 计划 。 使 用 ACS， 上 述 的 类 似 问 题 将 会 得 到 解决 。 不 
过 目前 ACS 技术 尚 不 完善 ,会 出 现 一 些 Bug， 导 致 某 些 游标 的 子 游 标 数 量 十 分 大 ， 从 而 影响 共 
享 池 和 SQL 执行 的 性 能 ， 在 使 用 时 需要 注意 。 
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3.2.4 OPEN CURSOR 和 OPEN_CURSORS 参数 


OPEN CURSORS 是 一 个 十 分 有 趣 的 参数 ， 经 常 有 DBA 会 发 现 自己 系统 中 的 打开 游标 数 非 
常 大 。 我 们 来 看 一 个 例子 。 


SQL>select sid, valuefromv$sesstat a,v$statname b where a.statistic#=b.statistic#and Em 
name=' 0pened cursors current' order by 2; 


SID VALUE 
5430 93 
3521 95 
4055 96 
4090 97 
2012 98 
1819 98 
5349 102 
1684 103 
1741 116 
4308 169 
1970 170 
1369 181 
4208 184 

887 214 
5215 214 
3518 214 

868 214 
1770 215 
4050 215 
1809 231 
3010 235 

762 237 

731 471 
4013 1066 
2648 1152 
2255 1172 
2322 2620 


这 个 系统 的 OPEN_CURSORS 参数 设置 为 3000， 而 会 话 中 当期 打开 游标 最 大 的 会 话 居然 达 
到 了 2620。 在 一 般 人 的 眼 里 ， 游 标 使 用 后 就 关闭 了 ， 打 开 的 游标 的 数量 应 该 不 会 太 多 。 难 道 应 
用 程序 出 现 了 游标 泄漏 ， 有 些 应 用 使 用 了 游标 没有 关闭 ?实际 上 , 我 们 对 打开 游标 的 概念 一 直 存 
在 误解 ， 认 为 只 有 正在 获取 的 游标 是 打开 状态 ， 而 一 旦 获取 结束 ,关闭 游标 后 ， 游 标 就 处 于 关闭 
状态 了 ， 因 此 一 个 会 话 中 打开 状态 的 游标 数量 应 该 很 少 。 事实 上 不 是 这 样 的 。 某 些 游标 在 程序 中 
已 经 关闭 了 , 但 是 Oracle 为 了 提高 游标 的 性 能 , 会 对 其 进行 缓冲 , 这 些 缓冲 的 游标 在 程序 中 的 关 
闭 只 是 一 种 软 关闭 ， 事 实 上 ， 在 会 话 中 并 未 关闭 ， 而 是 存放 在 一 个 游标 缓冲 区 中 。 

在 Oracle 9.2.0.5 之 前 ，OPEN_CURSORS 参数 的 作用 是 双重 的 , 一 方面 是 限制 一 个 会 话 打 开 
游标 的 总 量 ， 另 外 一 方面 ，OPEN_CURSORS 参数 也 作为 PL/SQL CURSOR 的 缓冲 。 在 PL/SQL 
中 ， 如 果 某 个 游标 关闭 了 ， 它 不 会 马上 硬 关 闭 ， 而 是 首先 保存 在 游标 缓冲 中 。 如 果 这 个 会 话 当 前 
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打开 的 游标 数量 还 没有 达到 OPEN_CURSORS 参数 的 值 , 那么 就 可 以 先 保持 打开 状态 。 如 果 当 前 
打开 的 游标 数量 已 经 达到 了 OPEN_CURSORS 参数 的 限制 , 那么 首先 会 关闭 一 个 被 缓冲 的 、 实 际 
当时 并 未 打开 的 游标 。 如 果 缓 冲 池 中 的 所 有 游标 都 是 实际 打开 的 ， 那 么 就 会 报错 ORA-1000: 
maximum open cursors exceeded, 

Oracle 9.2.0.5 以 后 ，OPEN_CURSORS 参数 不 再 承担 PL/SQL 缓冲 的 工作 ，PL/SQL 中 的 
SQL 也 可 以 使 用 SESSION. CACHED CURSORS 的 会 话 缓冲 了 。 这 个 参数 就 成 为 了 一 个 纯粹 
的 限制 。 

虽然 如 此 ，OPEN_CURSORS 参数 仍然 和 游标 的 缓冲 机 制 密切 相关 ， 因 为 这 个 参数 限制 了 当 
前 某 个 会 话 打开 游标 的 最 大 值 ,设置 一 个 较 大 的 OPEN_CURSORS 参数 ,可 以 避免 出 现 ORA-1000 
错误 ， 同 时 也 可 以 让 会 话 缓冲 更 多 的 游标 ， 改 善 SQL 解析 的 性 能 。 不 过 将 这 个 参数 设置 得 较 大 
会 占用 较 多 的 РСА 空间 ， 消 耗 一 定 的 物理 内 存 。 因 此 它 并 不 是 设置 得 越 大 越 好 ， 一 般 的 OLTP 
系统 中 ，1000 ~ 3000 就 足够 了 。 在 共享 服务 器 模式 的 系统 中 ， 该 参数 的 设置 要 略微 保守 一 些 ， 
因为 这 个 参数 武大 ， 占 用 的 SGA 空间 也 就 越 大 。 
另外 要 注意 的 是 ， 从 Oracle 9.0 开始 ， 这 个 参数 就 已 经 是 动态 的 了 ， 可 以 随时 动态 调整 。 


3.2.5 CURSOR SPACE FOR TIME 参数 


CURSOR SPACE FOR TIME 是 一 个 十 分 “霸道 ”的 参数 ， 自 从 Oracle 8i 引入 这 个 参数 以 
来 ,就 一 直 饱 受 争 议 。CURSOR_SPACE_FOR_TIME 的 引入 目的 是 减少 游标 锁 的 数量 ， 从 而 减少 
共享 池 相 关门 锁 的 争 用 。 

“CURSOR_SPACE_FOR_TIME=TRUE” 的 原理 是 ， 当 父 游标 被 开启 的 时 候 ， 所 有 的 子 游标 
及 其 关联 的 相关 对 象 全 部 被 锁 住 ， 从 而 确保 该 游标 所 有 的 相关 信息 都 是 一 致 的 , 而 且 是 完全 保存 
在 共享 池 中 的 ， 进 而 提高 游标 执行 时 的 效率 。 如 果 这 个 参数 没有 被 设置 ， 那 么 只 有 当 SQL 处 于 
执行 阶段 时 ， 相 关 的 对 象 才 会 被 锁 住 。 一 旦 执行 阶段 完成 ， 就 没 必 要 再 锁 住 整个 游标 了 。 在 上 一 
节 讨 论 OPEN_CURSORS 参数 的 时 候 , 我 们 知道 很 多 游标 执行 完毕 后 并 不 是 物理 关闭 的 , 而 是 放 
在 游标 高 速 缓存 里 ,那么 这 些 游标 就 会 被 锁 住 ， 无 法 被 释放 继续 使 用 。 直 到 会 话 退 出 ， 才 会 真正 
关闭 这 些 游标 ,而 直到 最 后 一 个 使 用 游标 的 会 话 退 出 ,该 游标 才能 被 换 出 。 这 样 就 可 能 导致 大 量 
的 共享 池 对 象 被 锁 住 ， 使 共享 池 碎 片 化 , 严重 时 会 导致 共享 池 无 法 分 配 足够 大 小 的 连续 空间 ， 系 
统 将 出 现 故 障 ， 其 至 宕 机 。 

虽然 这 个 参数 能 够 减少 共享 池 的 门 锁 争 用 , 但 是 它 也 有 很 大 的 副作用 ,就 是 会 增加 共享 池 碎 
片 的 机 会 。 因 为 只 要 某 个 游标 的 父 游标 没有 关闭 , 那么 该 游标 所 有 的 相关 对 象 都 会 被 锁 在 共享 池 
中 ,不 会 被 换 出 ， 这 样 就 加 大 了 共享 池 碎 片 化 的 趋势 。 如 果 存 在 大 量 这 样 的 游标 , 那么 共享 池 就 
会 变 得 十 分 零碎 ， 出 现 ORA-4031 错误 ， 宕 机 的 可 能 性 就 很 大 了 。 

正 是 因为 上 述 原因 ,使 用 CURSOR_SPACE_FOR_TIME 要 十 分 谨慎 ， 一 般 不 建议 使 用 。 
如 果 确 实 需要 使 用 该 参数 ， 就 要 确保 共享 池 是 较为 充足 的 ,并且 设置 该 参数 后 共享 池 碎 片 化 趋 
势 不 是 十 分 明显 。 如 果 使 用 了 这 个 参数 ， 建 议定 期 重启 数据 库 实例 ， 从 而 缓解 共享 池 碎 片 化 的 
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趋势 。 
从 10.2.0.5 版 本 开始 ， 库 缓存 锁 已 经 被 mutex 全 面 奉 代 ， 因 此 也 就 不 再 需要 这 个 参数 了 。 
CURSOR_SPACE_FOR_TIME 完成 了 其 使 命 ， 被 彻底 废除 了 。 


3.2. SESSION CACHED CURSORS 参数 和 OPEN_CURSORS Em 


SESSION CACHED CURSORS 参数 的 引入 是 个 偶然 。Oracle FORMS 的 开发 人 员 发 现 业务 
逻辑 要 求 表单 之 间 需 要 经 常 来 回 切换 ， 而 一 旦 某 个 表单 切换 到 另外 一 个 表单 ， 旧 表单 上 的 所 有 游 
标 就 必须 全 部 关闭 ,下 次 切换 回来 时 ， 又 需要 再 次 打开 ,， 这样 就 大 大 降低 了 表单 切换 的 效率 。 人 
们 开始 考虑 能 和 否 开发 一 种 类 似 于 软 关闭 的 方式 ,使 游标 不 被 真正 关闭 ,从 而 提高 表单 应 用 的 效率 。 
于 是 SESSION_CACHED_CURSORS 参数 就 应 运 而 生 了 。 在 UGA 中 建立 一 个 独立 的 游标 缓冲 池 ， 
将 常用 的 游标 缓冲 起 来 ,下 次 执行 时 可 以 直接 从 缓冲 池 中 取出 游标 , 不 需要 再 次 解析 。 这 个 缓冲 
池 和 OPEN_CURSORS 所 控制 的 游标 缓冲 池 是 不 同 的 ， 前 者 最 初 是 为 PL/SQL 中 的 CURSOR 服 
务 , 而 SESSION_CACHED_CURSORS 的 缓冲 在 9.2.0.5 版 本 之 前 是 不 能 缓冲 PL/SQL 中 的 游标 的 ， 
9.2.0.5 版 本 以 后 才 开 始 支 持 。 游 标 被 放 人 会 话 缓冲 池 中 的 前 提 是 被 多 次 解析 , 在 一 个 游标 被 解析 
3 次 后 ， 就 会 被 放 人 和 人 会话 缓冲 区 中 。 

SESSION_CACHED_CURSORS 参数 在 共享 池 优化 工作 中 是 十 分 常用 的 。 这 个 参数 的 主要 功 
能 是 将 某 个 会 话 中 常用 的 SQL CA. UGA 中 的 会 话 缓冲 区 里 , 以 便于 下 次 调用 , 这 样 就 不 需要 再 
做 解析 ， 从 而 减少 了 共享 池 的 争 用 。 

如 果 使 用 绑 定 变 量 的 目的 是 减少 硬 解析 ， 从 而 改善 共享 池 ， 提 高 并 发 能 力 ， 那 么 使 用 
SESSION CACHED CURSORS 参数 的 目的 就 是 减少 软 解析 ,从 而 进一步 提高 共享 池 的 性 能 。 对 
于 某 些 系统 而 言 , 不 仅仅 是 硬 解析 需要 优化 , 大 量 的 并 发 执行 , 使 软 解析 也 可 能 成 为 系统 的 瓶颈 ， 
相关 示例 的 AWR 报告 如 下 。 


Load Profile 


m Per Second Per Transaction 
Redo size: 1,989,039.62 12,816.67 
Logical reads: 181,739.18 1,171.06 
Block changes: 7,007.77 45.16 
Physical reads: 2,112.79 13.61 
Physical writes: 0.57 0.00 
User calls: 12,191. 86 78.56 
Parses: 8,958.80 51.13 
Hard parses: 49.07 0.32 
Sorts: 210.70 1.36 
Logons: 0.03 0.00 
Executes: 11,725.29 15:533 
Transactions: 155.19 


从 报告 中 可 以 看 出 ， 平 均 每 秒 执行 的 数量 为 11 725， 每 秒 的 解析 数量 为 8958。 在 这 种 情况 
下 ， 共 享 池 的 争 用 十 分 严重 ， 相 关 数 据 如 下 : 
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Instance Efficiency Percentages (Target 100%) 


Buffer Nowait %: 99.96 Redo NoWait % 
Buffer Hit %: 98.84 |n- memory Sort % 
Library Hit 9: 107.03 Soft Рагѕе % 
Execute to Рагѕе %: 23.59 Latch Hit % 
Parse CPU to Parse Elapsd %: 2.89 % Non- Parse CPU 
Shared Pool Statistics Begin End 
Memory Usage %: 9.52 9.51 


% SQL with executions>1: 94.13 94.34 
% Memory for SQL wlexec>1: 89.00 92.95 


% Total 
DB Ti me 


100.00 
100.00 
99.45 
95.60 
94.08 


Wait Class 
Concurrency 


Concurrency 
Concurrency 


op 5 Ti med Events 

Event Waits Time (5) 
atch: library cache 179,862 3,360 
CPU ti me 1,391 
atch: cache buffers chains 21,316 642 
atch: library cache lock 26,875 561 
atch: library cache pin 30,675 519 


Concurrency 


我 们 可 以 看 到 ， 虽 然 共享 池 的 命中 率 很 高 ,但 是 库 缓 存 门 锁 的 争 用 十 分 严重 。 相 关 等 待 接近 


总 体 的 50%。 在 这 种 极端 的 情况 下 ， 通 过 加 大 SESSION_CACHED_CURSORS 参数 ， 可 以 有 效 


地 减少 软 解析 的 数量 ， 从 而 缓解 共享 池 相关 门 锁 的 争 用 。 


针对 这 个 案例 ， 建 议 采 取 两 项 措施 ， 第 一 项 是 设置 SESSION_CACHED_CURSORS 为 200。 
参数 调整 后 并 发 量 会 大 幅度 提升 ， 并 发 量 增 加 后 DB Cache 的 压力 就 会 有 所 增加 ， 从 而 影响 整体 
的 优化 效果 。 为 了 保障 性 能 ， 应 同时 采取 第 二 项 措施 ,将 DB Cache 加 大 5 ~ 10GB。 

事实 证 明 加 大 SESSION_CACHED_CURSORS 参数 的 效果 十 分 明显 ， 共 享 池 门 锁 争 用 明显 


降低 ， 每 秒 平均 事务 数量 从 155 提高 到 300 左右 。 


为 什么 调整 SESSION. CACHED CURSORS 参数 会 有 这 么 大 的 效 


果 呢 ? 为 了 了 解 这 一 点 ， 


我 们 来 做 一 个 实验 ， 分 析 一 下 SESSION. CACHED. CURSORS 参数 对 library cache pin 和 library 


cache lock 的 影响 。 


在 分 析 library cache pin/lock 前 ， 首 先 需 要 了 解 10049 事件 。 从 10.2 版 本 开始 ，10049 事件 可 
以 全 面 监控 库 缓 存 的 PIN/LOCK 和 JINVALIDATION ， 其 参数 在 % 和 10g 版 本 中 有 所 不 同 。 
要 使 用 10049 事件 ,首先 需要 找 出 SQL 的 散 列 值 ， 用 散 列 值 的 低位 作为 LEVEL 的 高 位 ， 加 


上 0X2030 (TRACE PIN/LOCK )， 产 生 LEVEL 的 值 。 


var id number 
exec :id: =1099; 
select empno,ename from emp where empno=: id; 


select hash value from v$sqlarea where sql text like ‘select empno, ename%' 


HASH VALUE 
2892642140 

用 计算 器 看 看 十 六 进 制 
AC6A39B4 
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这 个 十 六 进 制 数 的 低位 是 39B4 ， 我 们 要 TRACE PIN/LOCK, ， 因 此 TRACE LEVEL 为 
39B42030, 转换 为 十 进 制 就 是 968106032. 下面 首先 将 SESSION_CACHED_CURSORS 设置 为 0， 
关闭 会 话 的 CURSOR CACHE ， 看 看 会 发 生 什 么 情况 。 


alter session set session cached cursors=0 
alter session set events '10049 trace name context forever,level 968106032' 


该 设置 对 相关 库 缓 存 的 PIN 和 LOCK 进行 跟踪 操作 。 准 备 结束 ， 通 过 多 次 执行 下 面 的 语句 
来 检查 library cache pin 和 library cache lock 的 情况 。 

exec :id:=1010; 

select empno,ename from emp where empno=:id; 


exec :id:=1011; 
select empno,ename from emp where empno=:id; 


可 以 看 到 ， 每 次 执行 ， 跟踪 文 件 中 的 PIN 和 LOCK 就 会 增加 。 


KGLTRCLCK kgl get hd = OxIFBCB8A4 KGL Lock addr = 0x20F75530 mode = N 
KGLTRCLCK kgl get hd = OxIFBCB7CO KGL Lock addr = 0x20FA8970 mode = N 
KGLTRCPIN kglpin hd = OxIFBCB7CO KGL Pin addr = 0x20F259D0 mode = 5 
KGLTRCPIN kgl pndl hd = OxIFBCB7CO KGL Pin addr = 0x20F259D0 mode = 5 
KGLTRCLCK kgl I kdl hd = OxIFBCB7CO KGL Lock addr = 0x20FA8970 mode = N 
KGLTRCLCK kgl I kdl hd = Ox1FBCB8A4 KGL Lock addr = 0x20F75530 mode = N 


首先 来 看 这 里 涉及 的 两 个 地 址 ，library_cache 的 跟踪 信息 如 下 : 


Bucket 14772 
LIBRARY OBJECT HANDLE: handle=1fbcb8a4 mutex-1FBCB958(1) 
name=select empno,ename from emp where empno=:id 
hash=cedceelccc9795f 332f72482ac6a39b4 ti mestampz12-24- 2007 21:55:26 
namespace=CRSR flags=RON/ KGHP/ TI M/ PNO/ SML/ KST/ DBN/ MTX/[120100d0] 
КККК- 0900-1111 =0000- 0001-0001 lockz0 pin=0 latch£éz3 hpc=0000 hlcz0000 
| wt =1FBCB900[1FBCB900, 1FBCB900] 1 tm=1FBCB908[{ 1FBCB908, 1FBCB908] 
pwt =1FBCB8E4[1FBCB8E4, 1FBCB8E4] ptm=1FBCB8EC[ IFBCB8EC, 1FBCB8EC 
ref =1FBCB920[1FBCB920, 1FBCB920] | nd=1FBCB92C[ IFBCB6F0, 23192730] 
LIBRARY OBJECT: obj ect =2052е5е4 
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD | oad=0 
CHILDREN: size=16 
child# able reference handle 


0 20520080 2052cd34 lf bcb7c0 


DATA BLOCKS: 
data# heap pointer status pins change whr 
0 23169fcc 2052e67c I/-/A/-/- 0 NONE 00 


Bucket 14772 total object count=1 
上 上面 的 信息 就 是 这 个 SQL 的 父 游标 的 句柄 ， 而 IFBCB7C0 是 其 子 游标 句柄 的 地 址 。 


LIBRARY OBJECT HANDLE: handle=1fbcb7c0 mutex=1FBCB874( 0) 
namespace=CRSR flags-RON/ KGHP/ PN0/[10010000] 

КККК- 0900-1111 =0000- 0000-0000 lockz0 pin=0 latch£éz3 hpc=0000 hlcz0000 
| wt Z1FBCB81C[IFBCB81C,IFBCB81C] | tm=1FBCB824[ 1FBCB824, 1FBCB824] 

pwt =1FBCB800[ 1FBCB800, 1FBCB800] ptm=1FBCB808[ 1FBCB808, 1FBCB808 

ref z1FBCB83C[2052CD34,2052CD34] | nd=1FBCB848[ 1FBCB848, 1FBCB848] 
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CHILD REFERENCES 
reference latch flags 
2052cd34 0 CHL[ 02] 

LIBRARY OBJECT last freed from HPD addn data CBK 


从 上 面 的 跟踪 信息 可 知 , 执行 SQL 过 程 中 , 需要 47 LOCK, 两 个 PIN。 那 么 如 果 是 被 缓存 


了 的 游标 会 怎么 样 呢 ? 

22:01:01 SQL> alter session set session cached cursors 
会 话 已 更 改 。 

22:14:35 SQL» select empno,ename from emp where empno=: 
未 选 定 行 
22:14:39 SQL» select empno,ename from emp where empno=: 
未 选 定 行 
22:14:42 SQL» select empno,ename from emp where empno=: 
未 选 定 行 
22:14:56 SQL» select empno,ename from emp where empno=: 
未 选 定 行 
22:16:09 SQL» select етрпо, епате from emp where empno=: 
相关 的 跟踪 信息 如 下 : 
*** 2007-12-24 22:16:21.122 
KGLTRCPIN kglpin hd = OxIFBBF998 KGL Pin addr = 
KGLTRCPIN kgl pnd hd = OxIFBBF998 KGL Pin addr = 


令 人 惊奇 的 是 ，library cache lock 不 见 了 ， 对 父 游标 的 


SESSION_CACHED_CURSORS 优化 分 析 过 程 的 一 个 直观 表现 。 为 什么 


施加 library cache lock WE? 我 们 先 来 看 父 游标 句柄 : 


Bucket 14772 
LIBRARY OBJECT HANDLE: handle=lfbcb8a4 mutex=1FBCB95 
name=select empno,ename from emp where empno=:id 
hash=cedceelccc9795f 332f72482ac6a39b4 ti mestampz12-2 
namespace=CRSR flags=RON/ KGHP/ TI M/ KEP/ PNO/ SML/ KST/ DB 


=20; 


0x21248078 mode S 
0x21248078 mode S 


s 都 消失 了 ， 这 就 是 
需要 对 子 游标 和 父 游标 


8(1) 


4-2007 22:14:39 
№ MTX/ [12010004] 


kkkk-dddd-I111 =0001-0001-0001 
| wt =1FBCB900[ 1FBCB900, 1FBCB900 
pwt =1FBCB8E4[ 1FBCB8E4, 1FBCB8E4 
ref =1FBCB920[ 1FBCB920, IFBCB920 
DEPENDENCY REFERENCES 
reference latch flags 


ock=N pin=0 latch#=3 hpc=0002 hl c=0002 
| t m=1FBCB908[ 1FBCB908, IFBCB908] 
pt m=1FBCB8EC[ 1FBCB8EC, IFBCB8EC] 
| ndz1FBCB92C[ 2329CBD8, 231B6A88 


20553df0 0 [60] 
LOCK OWNERS: 
lock user session count mode flags 
212383e8 2372d86c 2372d86c 1 N [00] 
LIBRARY OBJECT: obj ect =2059dea0 
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD | oad=0 
CHILDREN: size=16 
child# table reference handle 


0 205544a0 


20554154 1fbbf998 
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DATA BLOCKS: 
datas heap pointer status on change whr 
0 23230708 2059df38 I/P/A/-/- 0 NONE 00 
Bucket 14772 total object count=1 


可 以 看 出 ， 和 普通 的 库 缓存 不 同 ,lock 不 是 0, MEN, 这 说 明 在 该 对 象 上 已 经 有 一 个 空 锁 ， EE 
因此 不 需要 再 加 锁 了 。 接 下 来 再 看 看 子 游标 。 


LIBRARY OBJECT HANDLE: handle=lfbbf998 тиїех=1ЕВВЕА4С( 0) 
namespace=CRSR flags=RON/ KGHP/ PNO/ [10010000] 
КККК- 0900-1111 =0000-0041-0041 lockzN pin=0 latch#=3 hpc=0002 hl c=0002 
| wt =1FBBF9F4[1FBBF9F4, IFBBF9F4] |tm=1FBBF9FC[ 1FBBF9FC, 1FBBF9FC 
pwt =1FBBF9D8[1FBBF9D8, 1FBBF9D8] ptm=1FBBF9EO[{ 1FBBF9EO, 1FBBF9E0 
ref =1FBBFA14[ 20554154, 20554154] | nd=1FBBFA20[{ 1FBBFA20, 1FBBFA20] 

CHILD REFERENCES 

reference latch flags 


20554154 0 CHL[ 02] 
LOCK OWNERS: 

lock user session count mode flags 
20189814 2372d86c 2372d86c 1 N [00] 


LIBRARY OBJECT: object =20553cb4 
type=CRSR flags=EXS[0001] pflags=[0000] status=VALD | oad=0 
DEPENDENCIES: count=1 size=16 
dependency# table reference handle position flags 

0 2046173c 20461484 1fbcb668 24 DEP[ 01] 
READ ONLY DEPENDENCIES: countzl size=16 
dependency# table reference handle flags 

0 20554070 20553df0 lf bcb8a4 / ROD/ KPP[ 60] 
AUTHORI ZATIONS: count=1 size=16 minimum entrysizez16 
00000000 36000000 00020000 00000000 
ACCESSES: count=1 size=16 
dependency# types 


0 0009 
TRANSLATIONS: count=1 size=16 
origi nal final 


lfbcb668 1fbcb668 
DATA BLOCKS: 


datas heap pointer status pins change whr 
0 23217184 20553e04 I/P/A/-/- 0 NONE “00 
6 20461370 1fcfid3c I/-/A/-/- 0 NONE 00 


子 游标 上 同样 有 一 个 室 锁 。 由 于 被 缓存 了 的 游标 不 需要 再 进行 PIN 操作 ,这样 就 碱 少 了 共享 
池 的 门 锁 争 用 ， 有 效 地 提 AT SQL 并 发 执行 的 效率 。 这 就 很 好 地 解释 本 节 开始 时 那个 优化 案例 
的 效果 。 
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SESSION CACHED CURSORS 可 以 有 效 地 减少 软 分 析 , 那么 在 什么 情况 下 需要 减少 软 分 析 
呢 ? 我 们 看 看 代码 清单 3-5 所 示 的 查询 。 


代码 清单 3-5 


SQL» col cursor cache hits format a20 truncate 
SQL» col soft parses format a20 truncate 
SQL» col hard parses format a20 truncate 
SQL» select 
to char(100 * sess | calls, '9999990.00') 
to char(100 * (calls - sess - hard) / call 
to char(100 * hard / calls, '999990.00') | 
from 
( select value calls from v$sysstat where name 
( select value hard from v$sysstat where name 
( select value sess from v$sysstat where name 
2 3 4 5 6 1 8 
CURSOR_CACHE_HITS SOFT_PARSES HARD_PARSES 


|| '% cursor cache hits 

s, '999990.00') || '% soft parses 

| '% hard parses 

"parse count (total)' ), 
‘parse count (hard)' ), 
‘session cursor cache hits' ); 


从 上 面 的 查询 结果 来 看 ， 游 标 缓存 的 命中 率 是 85.34， 软 解析 的 比例 是 14.16% ， 硬 解析 的 比 
例 是 0.06% 。 目 前 这 个 系统 的 SESSION. CACHED CURSORS 参数 设置 为 200。 加 大 
SESSION_CACHED_CURSORS 参数 能 否 提 高 命中 率 , 进一步 减少 软 解析 呢 ? 我 们 可 以 用 代码 清 
单 3-6 所 示 的 查询 继续 分 析 。 


代码 清单 3-6 


Select 'session_cached_cursors' parameter, lpad(value, 5) value 


decode(value, 0, ' n/a', to char(100 * used / value, '990') |] '€*) usage 
from 
( select 
max(s.value) used 
from 


v$statname n, 
v$sesstat s 
where 
n.name = 'session cursor cache count' and 
s.statistic£ = n.statistic# 
|, 
( select 
value 
from 
v$parameter 
where 
name - 'session cached cursors 
) ; 


PARAMETER VALUE USAGE 


session cached cursors 200 100% 
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从 查询 结果 来 看 ，CACHE 的 使 用 率 是 100%。 这 个 SQL 实际 上 是 通过 会 话 的 信息 查找 会 话 
缓冲 使 用 的 最 大 值 ， 因 此 查询 结果 是 100% 并 不 一 定 就 说 明 SESSION_CACHED_CURSORS 参数 
太 小 了 ， 一 定 要 参考 上 面 的 软 解析 百分比 ， 综 合 分 析 。 如 果 有 必要 的 话 JH XA 
SESSION CACHED CURSORS 参数 ,还 可 以 进一步 减少 软 解析 。 一 般 来 说 ,在 一 个 充分 调 优 的 
OLTP 系统 中 ，SESSION CACHE 的 命中 率 可 以 达到 90% 其 至 95% 以 上 。 


3.27 CURSOR SHARING 和 游标 共享 


谈 到 共享 池 ， 就 不 得 不 提 及 CURSOR_SHARING 参数 。 有 些 应 用 可 能 写 得 不 够 好 ， 里 面 使 
用 了 大 量 的 非 绑 定 变量 ,针对 这 种 情况 ,Oracle 从 8.0 版 本 开始 支持 通过 设置 CURSOR_SHARING 
参数 来 共享 没有 使 用 绑 定 变量 的 类 似 SQL。 刚 开始 的 时 候 ，Oracle 只 是 提供 了 FORCE 设置 ， 强 
制 性 地 共享 类 似 SQL， 从 而 解决 了 未 使 用 绑 定 变量 导致 SQL 无 法 共享 的 问题 。 从 9i 开始 ， 
CURSOR SHARING 能 够 支持 SIMILAR 参数 值 。SIMILAR 选项 的 出 现 是 为 了 弥补 FORCE 设置 
的 不 足 。 在 8.1.6 和 8.1.7 这 两 个 版 本 中 ， 如 果 使 用 了 CURSOR_SHARING=FORCE, JZ HES 
探 将 不 再 进行 ,这 样 就 导致 了 部 分 应 用 在 使 用 CURSOR_SHARING 参数 后 ,执行 计划 出 现 偏 差 ， 
使 得 大 量 关键 SQL 采用 了 较 差 的 执行 计划 ， 导 致 系统 的 总 体 性 能 没有 提升 反而 下 降 。 在 9i 版 本 
中 使 用 SIMILAR ， 对 于 存在 柱状 图 的 列 ， 可 以 进行 绑 定 窥探 ， 从 而 解决 了 FORCE 产生 的 问题 ， 
这 样 既 可 以 共享 SQL， 又 不 会 产生 较 差 的 执行 计划 。 

似乎 一 切 都 很 完美 ， 不 过 由 于 实际 应 用 的 复杂 性 ，SIMILAR 又 引入 了 新 的 问题 。 对 于 
SIMILAR 如 何 判 断 SQL 是 否 可 以 共享 的 资料 十 分 有 限 ， 因 此 老 白 也 没有 对 此 进行 过 十 分 深入 的 
研究 ， 只 是 根据 Oracle Metalink 的 文档 了 解 到 ,使 用 了 类 似 <> between, like 和 != 这 些 判断 条 件 
的 SQL, Æ CURSOR SHARING-SIMILAR 时 是 无 法 共享 的 。 这 将 导致 某 条 SQL 由 于 
CURSOR SHARING = SIMILAR 而 被 替换 为 文本 ， 比 如 : 


SELECT * FROM TAB1 WHERE COL1>10; 
SELECT * FROM TAB1 WHERE COL1>20; 
SELECT * FROM TAB1 WHERE COL1>30; 


这 三 条 SQL 被 认为 是 同一 条 SQL: 

SELECT * FROM TAB1 WHERE COLI:'SYS B 0"; 

通过 下 面 的 示例 可 以 了 解 到 不 同 的 判断 条 件 对 CURSOR_SHARING=SIMILAR 情况 下 SQL 
共享 的 影响 : 


alter session set cursor sharingesimilar; 

select count(*) from t1 where object id»10; 
select count(*) from t1 where object id»20; 
select count(*) from t1 where object id»30; 
select count(*) from t1 where object idz10; 


select count(*) from t1 where object idz20; 
select count(*) from t1 where object idz30; 


col 591 text format або trunc 
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set line 132 
select sql_text,version_count from v$sqlarea 
where sql text like '% rom t1% 


SQL TEXT VERSI ОМ COUNT 
select count(*) from t1 where object id»:"SYS B 0" 3 
select count(*) from t1 where object idz:'SYS B 0" 1 
从 上 面 的 测试 可 以 看 出 ,“=” 条 件 的 SQL 被 很 好 地 共享 了 ,而 “>” 条 件 的 SQL 无 法 共享 ， 


另外 , 在 V$SQL_SHARED_CURSOR 中 ， 我 们 无 法 看 到 任何 不 能 共享 的 原因 。 

可 能 还 有 一 些 朋友 没有 看 出 其 中 的 问题 , SQL 无 法 共享 又 能 怎么 样 呢 ? 实际 上 , 在 生产 环境 
中 ， 如 果 存 在 大 量 这 样 的 SQL, 那么 这 些 SQL 就 会 由 于 CURSOR_SHARING 参数 的 设置 而 被 合 
并 为 一 条 SQL, 从 而 拥有 相同 的 父 游标 , 不 过 由 于 最 终 游 标 不 能 共享 , 因此 在 父 游 标 下 会 产生 大 
量 的 子 游标 ( 几 百 甚至 上 千 )。 在 访问 这 些 游标 时 ， 由 于 子 游标 的 数量 巨大 ， 查 找 相 关子 游标 的 
时 间 就 会 很 长 。 期 间 可 能 导致 大 量 库 缓存 或 者 MUTEX 的 门 锁 争 用 。 上 千 个 无 法 共享 的 游标 共享 
一 个 父 游 标 , 其 效率 可 能 还 不 如 让 每 个 游标 都 拥有 独立 的 父 游 标 。 虽然 这 会 占用 更 多 的 共享 池 空 
间 ， 但 是 如 果 共 享 池 是 够 大 ， 其 访问 过 程 中 的 库 缓 存 和 MUTEX 相关 门 锁 等 待 都 会 少 很 多 。 

实际 上 ，Oracle 118 提供 了 更 为 优秀 的 游标 共享 算法 ， 既 避免 了 类 似 CURSOR_SHARING= 
FORCE 的 执行 计划 不 准确 的 问题 , 又 避免 了 CURSOR_SHARING=SIMILAR 的 大 量 游标 不 能 共享 
的 问题 。 这 种 解决 方案 就 是 118 版 本 中 的 ACS。 ТЕ ACS 启用 的 情况 下 , 绑 定 帘 探 技术 得 到 了 发 挥 ， 
在 判断 游标 是 否 可 以 共享 的 时 候 , 会 根据 绑 定 变 量 的 值 进行 分 析 。 如 果 值 域 对 应 的 选择 性 可 以 使 
用 原 有 的 执行 计划 ， 就 共享 SQL， 否 则 就 创建 一 个 子 游标 。 这 种 技术 既 解 决 了 游标 共享 的 问题 ， 
又 有 效 地 避免 了 因 绑 定 变 量 值 不 同 而 采取 不 同 执行 计划 的 问题 ， 可 以 算是 一 种 两 全 其 美的 方法 。 

如 果 使 用 ACS, 那么 对 于 没有 使 用 绑 定 变量 的 应 用 , 我 们 只 需要 使 用 CURSOR. SHARING- 
FORCE, 其 他 的 事情 就 交 给 ACS 去 完成 了 。 实 际 上 , 在 118 的 早期 版 本 中 ,ACS 的 Bug 比较 多 ， 
还 是 有 可 能 出 现 产 生 大 量子 游标 的 情况 ， 使 用 者 要 十 分 小 心 。 如 果 发 现 这 个 问题 ， 应 马上 关闭 
ACS， 这 时 我 们 可 以 通过 设置 “OPTIMIZER_EXTENDED_CURSOR_、SHARING_REL=NONE 来 
关闭 ACS 的 功能 。 相 关 Bug 可 能 导致 的 问题 如 表 3-2 所 示 。 


表 3-2 
Bug NO 问题 描述 影响 版 本 
10182051 有 多 个 绑 定 变量 的 SQL, 在 V$SQL 中 的 IS_SHARBLE=Y, 但 是 有 11.2.0.2 (11.2.0.3 修 复 ) 
大 量 不 同 的 版 本 
7213010 可 在 V$SQL_CS_SELECTIVITY 中 看 到 一 个 CURSOR 下 存在 大 量 11.1.0.6 (11.1.0.7 修 复 ) 
的 equivalent / overlapping 
6644714 可 在 V$SQL_SHARED_CURSOR 中 看 到 大 量 CHILD CURSOR 的 11.1.0.6 (11.1.0.7 修 复 ) 


LOAD_OPTIMIZER_STATS='Y' 


此 外 ,如 果 我 们 在 11g 版 本 的 数据 库 中 启用 了 ACS ,并 使 用 了 CURSOR_SHARING=SIMILAR， 
可 能 会 导致 十 分 严重 的 问题 一 一 大 量 的 游标 被 合并 了 , 但 是 不 能 共享 , 一 个 父 游 标 下 存在 大 量 不 
可 共享 的 子 游标 。 因 此 ,在 lig 版 本 中 ， 如 果 开 启 了 ACS 功能 ， 那 么 就 不 建议 使 用 CURSOR_ 
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SHARING=SIMILAR。 在 Oracle 12C 版 本 中 ，CURSOR_SHARING=SIMILAR 已 被 彻底 禁止 (不 
再 支持 这 个 设置 )。 


3.28 ”游标 的 关闭 


可 能 很 多 DBA 都 会 碰 到 这 样 一 件 十 分 奇怪 的 事情 ， 就 是 某 个 会 话 中 打开 的 游标 数量 会 十 分 Em 
庞大 ， 比 如 ， 在 某 个 生产 系统 中 进行 这 样 的 查询 : 


select sid,b.name,a.value from v$sesstat a,v$statname b where 
a.statistic#=b.statistic# and b.statistic#=3 order by 3 


SI D NAME VALUE 
3008 opened cursors curren 214 
2245 opened cursors curren 214 
5314 opened cursors curren 215 
3233 opened cursors curren 215 
2168 opened cursors curren 230 
4535 opened cursors curren 233 
5222 opened cursors curren 234 
4394 opened cursors curren 294 

876 opened cursors curren 310 
1265 opened cursors curren 325 
2320 opened cursors curren 326 
1783 opened cursors curren 331 

134 opened cursors curren 343 

987 opened cursors curren 344 
2241 opened cursors curren 357 

988 opened cursors curren 310 
1055 opened cursors curren 382 
5169 opened cursors curren 393 

302 opened cursors curren 411 
1276 opened cursors curren 422 

191 opened cursors curren 433 
1649 opened cursors curren 638 
4049 opened cursors curren 650 
3853 opened cursors curren 664 
1253 opened cursors curren 692 

370 opened cursors curren 822 
2664 opened cursors curren 834 
4145 opened cursors curren 925 
2322 opened cursors curren 2622 


为 了 简洁 , 老 白 只 截取 了 部 分 查询 结果 。 从 这 些 结果 上 看 , 会 话 中 打开 游标 的 数量 都 超过 了 

200 个 , 最 多 的 甚至 高 达 2622 个 。 一 般 的 应 用 程序 都 会 在 游标 使 用 完毕 后 将 其 关闭 ,怎么 会 产生 

么 多 打开 的 游标 呢 ? 难道 我 们 碰 到 了 游标 泄漏 ? 可 是 如 果 出 现 了 游标 泄漏 , 为 什么 应 用 没有 报 
错 ， 而 系统 还 能 够 正常 运行 呢 ? 要 回答 这 些 问 题 ， 就 需要 了 解 游标 关闭 的 相关 知识 。 

当 一 个 游标 使 用 完毕 后 , 程序 就 会 将 这 个 游标 关闭 。 不 过 由 于 前 面 几 节 介 绍 的 一 些 缓冲 技术 

的 存在 , 游标 关闭 分 为 软 关 闭 和 硬 关 闭 两 种 。 软 关闭 的 游标 虽然 被 客户 端 程序 关闭 了 , 但 是 实际 

上 在 游标 缓冲 中 , 仍 处 于 打开 状态 。 这 就 是 我 们 经 常 能 够 发 现 的 会 话 中 存在 大 量 打开 状态 游标 的 
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主要 原因 。 实际 上 ， 如果 系统 没有 出 现 游标 溢出 ,存在 大 量 软 关闭 的 游标 不 会 对 系统 产生 太 大 的 
影响 ，Oracle 会 自动 维护 这 个 游标 缓冲 区 ,使 之 较为 高 效 地 运作 ， 同 时 不 会 因为 打开 的 游标 数量 
太 多 而 导致 正常 使 用 的 游标 无 法 打开 。 

只 有 当 游 标 被 硬 关闭 了 , 它 和 会 话 之 间 的 联系 才 会 彻底 断 掉 。 将 来 这 个 会 话 要 再 次 执行 同一 
SQL 时 ， 就 需要 重新 创建 游标 的 相关 数据 结构 了 。 


3.2.9 互 斥 锁 和 游标 

当 我 们 还 纠结 于 library cache pin 这 类 等 竺 事件 的 时 候 , 突然 发 现 , 10.2 的 系统 中 library cache 
pin 等 相关 门 的 等 待 比 9i 版 本 要 少 得 多 ， 而 带 有 互 斥 锁 机 制 的 等 待 事件 出 现 了 ， 且 共享 池 的 问题 
往往 也 体现 在 这 些 事件 上 。 比 如 ， 在 一 个 10.2.0.3 的 АМЕ 报告 中 ， 我 们 会 看 到 : 


Top 5 Timed Events 

Event Waits Time(s) 
atch: row cache objects 942 13,072 
ibrary cache: mutex X 3,179 2,382 
atch: shared pool 2,980 1,559 
DB CPU 1,101 
0g file sync 21,402 322 


Avg wait(ms) % DB Ti me Wait Class 


13877 49.73 Concurrency 
749 9.06 Concurrency 
523 5.93 Concurrency 

4.19 
12 1.23 Co mmi t 


这 里 的 library cache: mutex X 等 待 出 现在 TOPS EVENT Hi 另外 , 下 面 的 信息 来 自 于 10.2.0.4 


的 AWR 报告 


Top 5 Ti med Events 


Event Waits Time(s) Avg wait(ms) % Total Wait Class 
Call Ti me 

cursor: pin S wait on X 18,568,538 181,950 10 209.2 Concurrency 

library cache load lock 10,314 29,581 2,868 34.0 Concurrency 

latch: library cache 134,719 26,156 199 30.8 Concurrency 

RDBMS ipc reply 12,258 23,018 1,878 26.5 Other 

latch: row cache objects 203,029 19,527 96 22:5 Concurrency 


其 中 排 在 第 一 位 的 是 cursor: pin S wait on X， 这 些 新 出 现 的 等 待 事件 是 什么 含义 呢 ? 要 想 解 
释 它 们 ， 我 们 必须 首先 了 解 一 个 从 Oracle 10е 才 开 始 引 入 的 新 的 串 行 机 制 一 一 互 斥 锁 机 制 


(MUTEX ). flit d dt ek 21% 
UNIX ЖЭ FP 522 AY 5 Fe BL 


此 在 多 线程 纪 


程 时 往往 会 采用 更 为 轻 量 级 的 锁 机 人 


il 


程 的 朋友 可 能 都 了 解 UNIX 上 的 信号 灯 机 制 。 信 号 灯 是 
央 ， 而 这 种 机 制 是 一 种 重量 级 的 锁 机 制 ， 其 成 本 较 高 ， 


互 斥 锁 机 制 。 互 斥 锁 机 制 是 一 种 轻 量 级 的 


同步 锁 机 制 ， 通 过 维护 一 个 计数 顺和 一 个 等 待 队列 来 实现 互 斥 。 

Oracle 的 互 斥 锁 和 操作 系统 层面 的 互 斥 锁具 有 一 定 的 相似 性 ,不 过 并 不 是 相同 的 机 制 .Oracle 
的 互 斥 锁 是 由 КОХ 层面 提供 的 ， 和 门类 似 ， 它 也 是 采用 操作 系统 的 原子 操作 ， 以 Compare And 
Swap (CAS ) 的 方式 来 自 旋 获 取 相 关 的 互 斥 锁 。 由 于 目前 的 绝 大 多 数 CPU 都 已 经 提供 了 这 种 指 
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令 集 ， 因 此 互 斥 锁 机 制 可 以 利用 硬件 的 特性 ， 获 得 很 好 的 执行 效果 。 不 过 对 于 一 些 不 支持 CAS 
H Н) CPU 来 说 , 互 斥 锁 的 成 本 会 大 大 增加 , 这 也 是 在 一 些 HP PA-RISC 系统 上 运行 的 10g R2 
系统 经 常会 出 现 cursor: pin S wait X 等 待 事件 的 主要 原因 。 
Oracle 互 斥 锁 的 结构 十 分 简单 ， 代 码 清单 3-7 是 老 白 所 理解 的 KGX 互 斥 锁 的 结构 说 明 。 


代码 清单 3-7 
struct KGX MUTEX { 


long kgx mutex; 

ub4 kgx mutex gets 

ub4 kgx mutex sleep; 

ub4 kgx mutex idn (mutex 唯一 性 标识 ) ; 


} 

从 前 文中 我 们 了 解 了 用 互 斥 锁 替代 library cache pin ， 其 执行 效率 会 有 较 大 的 提高 。 另 外 一 个 
ЖА, APR REEMA, CAR ABI Р АН, Leone AB КОН 
结构 中 。 针 对 CURSOR STAT， 我 们 来 看 一 个 例子 。 


SQL> oradebug setmypid 
Statement processed 
SQL» oradebug dump cursor stats 1; 
Statement processed 
SQL» 
Bucket 1 Mutex 0x660cd02c(0,0) tc 1 fc 0 
PARENT 0x65c65458 sglidz0x7bf 48001 phd = 0x68307228 

CHILD 0x6560e4d0 planhsh=0 cnum=0 flags=0x0 

Parse Count =36 

Disk Reads =0 

Disk Writes=0 

Buffer Gets =2920 

Rows Processed=538 

Serializable Aborts=0 

Fetches =0 

Execution Count =538 

PX Server Execution Count =0 

Full Execution Count =538 

CPU ti те =120130 

Elapsed Ti mez120130 

Avg Hard Parse Ti me=388 

Application Ti mez0 

Concurrency Ti me=0 

Cluster/RAC Ti me=0 

Userl/ O Ti me=0 

Plsql interpretor Ті me=0 

| VM Ti me=0 

Sorts=0 


可 以 看 出 , 这 个 CURSOR STAT BUCKET Æ H MUTEX 0x660cd02c 来 保护 的 。 在 Oracle 10.2 
中 ， 只 要 参数 kks_use_mutex_pin=true， 那 么 MUTEX 就 会 被 用 于 PIN library cache object, 在 
10.2.0.2 或 者 更 高 的 版 本 中 ， 这 个 参数 默认 就 是 TRUE。 在 11g 版 本 中 ， 互 斥 锁 的 使 用 更 为 广泛 ， 
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已 知 


的 互 斥 锁 种 类 包括 CURSOR PARENT, CURSOR PIN CURSOR STAT、 库 缓存 、 散 列表 等 。 


以 往 在 使 用 library cache pin 时 ， 一 个 门 锁 要 维护 一 组 对 象 ( 比如 一 组 HASH Bucket )， 而 互 斥 锁 

是 谍 和 到 对 象 内 部 的 , 因此 一 个 互 斥 锁 仅 仅 保护 一 个 特定 的 对 象 , 这 就 大 大 提高 了 互 斥 锁 并 发 使 
用 的 效率 。 

互 斥 锁 机 制 提高 了 共享 池 中 对 象 并 发 访问 的 效率 , 特别 是 提高 了 游标 并 发 的 效率 。 不 过 互 斥 


锁 也 会 
锁 相 


会 带 来 一 些 新 的 问题 ， 特 别 是 对 于 我 们 DBA 来 说 ， 可 能 会 感到 十 分 的 迷 茫 。 如 果 碰 到 互 斥 
关 的 问题 ， 我 们 该 如 何 处 理 呢 ? 实际 上 ，Metalink 中 的 相关 文档 是 十 分 有 用 的 。 

口 Troubleshooting "library cache: mutex X" waits. [ID 1357946.1] 

О FAQ: "cursor: mutex.. / cursor: pin.. / library cache: mutex ..” Type Wait Events [ID 1356828.1] 


О How to Determine the Blocking Session for Event: "cursor: pin S wait on X” [ID 786507.1] 
口 WAITEVENT: "library cache: mutex X” [ID 727400.1] 
根据 这 几 篇 文章 ， 老 白 也 对 一 些 主要 的 等 待 事件 进行 了 整理 


在 这 里 和 大 家 共享 ， 如 表 3-3 


所 示 。 
表 3-3 
等 待 事件 详细 说 明 
cursor: mutex S 说 明 : 以 共享 模式 (S) 或 者 排他 模式 (X) 获取 父 游 标 或 者 访问 V$SQLSTAT 的 时 候 出 
cursor: mutex X 现 的 等 待 。 如 果 以 X 模 式 获 取 ， 一 般 会 用 来 装载 子 游标 或 者 修改 SQL STAT BUCKET, 这 
种 等 待 有 三 个 参数 : РІ: MUTEX 的 IDN; P2; MUTEX 的 值 ，P3: 位 置 代 码 (Oracle 开发 
人 员 根 据 这 个 代码 知道 是 在 代码 的 哪个 位 置 发 生 的 等 待 ， 其 定义 在 kg1l0.h 中 ) 
可 能 的 原因 : 
频繁 的 硬 解 析 
有 一 些 游标 的 版 本 数量 太 多 
游标 存在 大 量 的 INVALID 和 RELOAD 
Воз 
查找 BLOCKING ; 在 V$MUTEX_SLEEP_HISTORY 中 ， 根 据 p2 参 数 和 REQUESTING 
SESSION 查找 
cursor: pin S 说 明 : 以 共享 模式 或 者 排他 模式 获取 游标 ， 由 于 不 兼容 访问 而 出 现 的 等 待 


cursor: pin X 


可 能 的 原因 : 同上 
查找 BLOCKING: 同上 


library cache: mutex X WEBB: 以 共享 模式 或 者 排他 模式 在 访问 某 个 库 缓存 对 象 时 ， 由 于 不 兼容 访问 出 现 的 等 竺 


library cache: mutex X 


3.3 


可 能 的 原因 : 同上 
分 析 方 法 : 参考 Troubleshooting “library cache: mutex X” waits. [ID 1357946.1] 


共享 池 的 相关 参数 
共享 池 相关 的 参数 如 表 3-4 所 示 ( 和 共享 池 相 关 的 参数 不 止 下 面 几 个 ,不 同 的 版 本 会 有 所 不 
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同 ， 本 表 仅 列 出 了 一 些 DBA 常用 的 参数 )。 
表 3-4 
参数 名 称 参数 简介 默 认 值 
SHARED POOL SIZE 共享 池 的 大 小 。 在 10g 版 本 之 前 ,该 参数 控制 共享 池 的 大 10g, 116 
小 ; 在 8 或 者 更 早 的 版 本 中 , 该 参数 一 旦 设置 , 实例 重启 ”版 本 默认 
前 无 法 修改 。 从 9i 版 本 开始 可 以 动态 修改 (在 (АО (使 
SGA_MAX_SIZE 支 持 的 情况 下 ) ， 从 10g 版 本 开始 这 个 ”用 自动 共 
参数 是 可 以 自动 管理 的 ， 一般 情况 下 可 以 设置 为 0, 让 享 内 存 管 
Oracle 自己 管理 。 不 过 有 经 验 的 DBA 一 般 会 给 这 个 参数 M) 
设置 一 个 值 ， 即 共享 池 的 最 小 值 ， 自 动 共 享 内 存 管理 和 
自动 内 存 管理 都 无 法 将 共享 池 缩 小 到 小 于 这 个 值 的 容量 
SHARED_POOL_RESERVED_SIZE 保留 地 的 大 小 ， 默 认 情况 下 被 设置 为 共享 地 的 5%。 保 留 ” 共享 池 的 
池 是 分 配 空间 给 大 对 象 使 用 的 ， 如 果 在 共享 地 中 无 法 找 5% 
到 足够 大 的 连续 空间 ，Oracle 会 从 保留 地 中 为 其 分 配对 
象 , Oracle 通 过 一 个 参数 对 大 对 象 进 行 认定 ( 稍 后 会 介绍 ) 
SHARED POOL RESERVED MIN ALLOC 设 定 可 以 在 保留 池 中 分 配 空间 的 大 对 象 的 最 小 值 。 在 大 4400 
多 数 共享 池 争 用 较为 严重 的 系统 中 ， 将 此 参数 设置 为 
4000 一 4200 是 比较 合适 的 。 从 8 版 本 开始 , 该 参数 变 为 隐 
含 参 数 ， 大 家 使 用 时 要 在 前 面 加 上 下 划 线 “_”, 而 且 无 
法 通过 show parameter 显 示 
CURSOR_SHARING 设置 共享 游标 的 策略 ， 黑 认为 EXACT， 还 可 以 设置 为 EXACT 


OPEN_CURSORS 
SESSION_CACHED_CURSORS 


_KGHDSIDX_COUNT 


SGA_TARGET 
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FORCEZSIMILAR, 设置 为 FORCE 或 者 SIMILAR 时 ,可 
以 强制 将 未 使 用 绑 定 变 量 的 SQL 合并 为 一 个 ， 从 而 减少 
游标 的 硬 解析 ， 提 高 共享 池 的 性 能 。 当 设置 为 SIMILAR、 
时 ， 在 某 些 条 件 (比如 between、!=、<>) 下 不 会 共享 游 
标 ， 当 设置 为 FORCE 时 ， 可 以 强制 共享 游标 
一 个 会 话 可 以 打开 的 游标 数量 的 上 限 。 在 共享 池 较 为 充 
足 的 情况 下 ， 加 大 该 参数 可 以 改善 游标 的 访问 性 能 

一 个 会 话 可 以 缓冲 的 游标 数量 的 上 限 ， 加 大 此 参数 ， 可 
以 减少 软 解析 ， 进 一 步 提 高 SQL 并 发 的 性 能 
共享 池 的 子 池 数量 ，Oracle 默 认 根 据 共享 池 的 大 小 以 及 
CPU 的 数量 设 定 ， 最 大 为 7。 如 果 共 享 池 碎片 化 程度 较 严 
重 ， 不 使 用 默认 的 配置 ， 减 少子 池 数 量 ， 可 以 对 此 有 所 
缓解 

严格 来 讲 ，SGA_TARGET 不 能 算是 共享 池 的 参数 ， 而 
是 SGA 的 参数 ， 如 果 设 置 了 SGA_TARGET>0，, 那么 就 
启用 了 共享 内 存 自动 管理 ， 这 样 就 不 需要 再 设置 
SHARED_POOL_SIZE 等 参数 了 ,Oracle 会 自动 进行 调 
整 。 不 过 我 们 还 是 建议 在 启用 了 SGA 自动 管理 
(ASMM) 的 系统 中 ,设置 共享 池 的 相关 参数 (相当 于 
设 定 其 最 小 值 ) 


共享 池 出 现 故 障 一 般 都 会 导致 严重 的 后 果 一 一 系统 变 慢 、 挂 起 甚至 实例 宕 掉 。 由 于 共享 池 的 
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复杂 性 ， 其 故障 分 析 往 往 十 分 复杂 ， 牵 涉 到 的 问题 很 多 。 因 此 共享 池 故 障 分 析 也 是 DBA 应 该 掌 
握 的 重要 技能 。 

一 般 来 说 ， 共 享 池 故障 分 为 共享 池 不 足 、 雁 片 化 、 门 争 用 严重 等 几 个 方面 ,本 节 就 从 著名 的 
ORA-4031 错误 说 起 。 


3.4.1 著名 的 ORA-4031 


ORA-4031 是 一 个 十 分 著名 的 错误 。 在 共享 池 中 分 配 内 存 的 时 候 , 共享 池 无 法 满足 分 配 需求 ， 
从 而 报错 ， 这 就 是 ORA-4031。 如 果 这 个 错误 出 现在 一 般 性 的 操作 上 ,那么 该 操作 会 失败 ， 而 如 
果 出 现在 核心 后 台 进程 的 核心 操作 方面 , 那么 就 可 能 会 导致 该 核心 后 台 进 程 骨 泪 , 从 而 使 数据 库 
实例 宕 掉 。 在 Oracle 10g 之 前 ，ORA-4031 是 一 个 十 分 难 缠 的 问题 ， 而 且 会 带 来 一 系列 问题 ， 让 
很 多 DBA 头疼 。Oracle 10g 共享 内 存 自 动 管理 技术 (ASMM ) 的 引入 , 使 ORA-4031 在 10g 系统 
中 的 危害 大 幅 减 少 了 。 

曾经 有 朋友 问 我 ， 在 10g 中 使 用 了 共享 内 存 自 动 管理 ， 是 不 是 就 永远 不 会 再 出 现 ORA-4031 
了 呢 ? 答案 当然 是 否定 的 ,在 10g 的 数据 库 中 仍然 会 出 现 ORA-4031， 代 码 清单 3-8 是 一 些 来 自 
10.2.0.4 RAC 的 数据 。 


代码 清单 3-8 


SQL» column indx heading "indx|indx пит" 
SQL» column kghlurcr heading "RECURRENT| CHUNKS" 
SQL» column kghlutrn heading "TRANSI ENT| CHUNKS" 
SQL» column kghlufsh heading "FLUSHED| CHUNKS" 
column kghluops heading "PINS AND|RELEASES" 
column kghlunfu heading "ORA-4031| ERRORS" 
column kghluNFS heading "LAST ERROR|SIZE" 
select 

i ndx, 

kghl urcr, 

kghl utrn, 

kghl uf sh, 

kghl uops, 

kghl unf u, 

kghl uNFS 

from 
sys.x$kghlu 
where 
inst id = userenv('Instance' 

I 


indx RECURRENT TRANSIENT FLUSHED PINS AND ORA-4031 LAST ERROR 


indx num CHUNKS CHUNKS CHUNKS RELEASES ERRORS SIZE 
0 0 20 0 20 0 0 
1 0 33 0 33 0 0 
2 0 29 0 29 0 0 
3 0 41 0 41 0 0 
4 0 29 0 29 0 0 
5 0 21 0 21 0 0 
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0 0 25 0 25 0 0 
7 55699 77858 243617195 1849542855 37334 4080 
8 69805 77705 251191900 1951901477 38678 4112 
9 91542 123255 245895667 1903437218 15445 4192 
10 91052 153817 244551473 1575983524 49619 4112 
11 49436 70082 222306066 1187087832 35028 4080 
12 63125 100818 221747017 2048101139 49394 4112 
13 82694 137315 219639529 1724460158 47184 2360 


从 上 面 的 数据 可 以 看 出 ， 这 是 一 个 RAC 系统 ， 其 中 实例 1 的 负载 很 小 ，SUBPOOL 0 - 6 rh 
不 过 在 7~ 13 这 七 个 子 池 中 都 出 现 过 大 量 的 ORA-4031。 为 什么 在 这 里 
有 大 量 的 ORA-4031 出 现 ， 但 是 系统 并 没有 那么 多 错误 呢 ? 这 就 是 ASMM 的 功劳 。 由 于 ASMM 


的 pin 和 release 都 很 少 ， 


功能 的 存在 ， 当 共享 池 出 现 不 足 的 时 候 ,， 可 以 通过 动态 扩展 共享 池 来 解决 问题 ， 
些 ORA-4031， 也 不 会 引起 实例 宕 掉 这 样 的 问题 。 但 如 果 在 9i 系统 中 出 现 这 种 情况 就 麻烦 了 ， 当 


某 个 核心 后 台 进 程 遇 到 了 ORA-4031， 必 然 会 导致 实例 宕 掉 。 


其 实在 Oracle 的 一 些 Metalink 文档 中 有 很 全 面 的 关于 ORA-4031 诊断 方法 的 阐述 ,大 家 如 果 
有 兴趣 可 以 去 查阅 (读者 如 果 没 有 Metalink 账号 , 可 以 在 www.oraclefans.cn 论坛 发 帖 , 老 白 会 帮 


助 大 家 上 传 这 些 文档 )。 


[ID 146599.1] 


90%28domainl d=ORA4031%29%29 


进入 后 , 可 以 按照 导航 要 求 上 传 文件 , 回答 相关 问题 , 最终 获 得 分 析 结 果 , 如 图 3-5 和 图 3-6 


所 示 。 


О Master Note for Diagnosing ORA-4031 [ID 1088239.1] 
О Diagnosing and Resolving Error ORA-04031 on the Shared Pool or Other Memory Pools [Video] 


口 Troubleshooting and Diagnosing ORA-4031 Error [Video] [ID 396940.1] 
Oracle 也 提供 了 一 个 诊断 工具 ， 和 帮助 用 户 分 析 ORA-4031 问题 ， 拥 有 MOS 账号 的 用 户 可 以 
直接 上 传 ALERT LOG, TRACE 文件 、AWR 报告 等 ， 只 需 输入 下 列 网 址 : 


https://support.oracle.com/CSP/ui/flash. ht ml #tab=Dashboar d%28page=GRHome&i d=gkzpuq 


因此 即使 出 现 一 


Step 1: Describe Problem 


2) Troubleshoot а new issue 


Problem Details 


What would you like to do? 


Review a Diagnostic Guide (Common issue causes and solutions) 


Do you have a default (non-incident) trace file corresponding to the first occurrence of ORA-04031 Error? + | VES 


Exit Wizard 


ыы) 


Step 2: Upload Files 
Please upload an alert log and a trace file, Alternatively, you can upload an IPS package that was generated when you encountered the 4031 error. The AWR report is optional, but if you can provide one, it will help 
further refinement of the diagnosis. 
File Type Fie Name See Fie Status 
Alertiog @ alert_kf2.log Browse | $715КВ 11% LOADING 11% 
tracefile @ kf2_cjq0_1253652.tre Browse. | 8520KB 8% LOADING 7% 
25085) 
AWR @ Browse... 
Ө 
IPS Package @ Browse... 
Exit Wizard Back 


图 3-6 


此 外 ,还 可 以 上 传 IPS 包 ( 如 果 你 是 11g 的 用 户 ,ADR 中 提供 了 IPS 服务 一 一 Incident Packaging 
Services， 可 以 通过 ADRCI 来 生成 相应 的 IPS E )。 上 传 后 ， 点 击 Next 按钮 就 可 以 进行 分 析 了 ， 
如 图 3-7 所 示 。 


Step 3: Review Recommendations 


Enter a report name and dick Finish to save. 


B Print E Email 


[Issue | Resolution | 
Primary Issue: @ Issue Detected 
cursor. sharing = SIMILAR: potential cause of high reloads Recommended Solution: 
The analysis shows that reloads are very high on this 1) Please determine if CURSOR_SHARING is necessary for your environment. If it is not necessary, please remove the 
database and that parameter parameter. à 
CURSOR, SHARING-SIMILAR. The high reloads can be a B 
side-effect of using CURSOR, SHARING-SIMILAR and is 1fCURSOR SHARING is necessary for your environment, please use a setting of FORCE instead of SIMILAR. 
likely to be the culprit of ORA-04031. We highly recommend 
you refrain from using that setting. NOTE: Changes to CURSOR, SHARING can affect performance on the database. Any change to this setting should be tested to investigate 

the extent of performance impacts for your application. 

This issue could occur if in init.ora parameter of your Alert 
log, cursor. sharing = SIMILAR, AND in LIBRARY CACHE References 
STATISTICS" of trace file, reloads of CRSR are greater = 
than Ena поп. MOTE: 1460017 + ANNOUNCEMENT: Rameneatinn the menar chainn ТМП AN! natin 


Are these recommendations helpful? (Q Yes, problem solved!  ( )Don'tknow, still untested ( )No! Create SR 


Can you provide feedback? Let us know hov 


e can improve this process 


Exit Wizard 


图 3-7 
最 后 查看 结果 ， 如 图 3-8 所 示 。 


[Troubleshooting Report: 


Issue Resolution 


Primary Issue: Recommended Solution: 
cursor sharing = SIMILAR: potential cause of high reloads D pleas determine H CURSOR SHARING ls necessary for your 
š = A environment. If it is not necessary, please remove the 

The analysis shows that reloads are very high on this database and that parameter irámetec 

CURSOR SHARING-SIMILAR. The high reloads can be a side-effect of using P CURSOR. SHARING is necessary for your environment, please 

CURSOR SHARING- SIMILAR and is likely to be the culprit of ORA-04031. We highly recommend you = m 

refrain from using that setting. use a setting of FORCE instead of SIMILAR. 

This issue could occur if in init.ora parameter of your Alert log, cursor_sharing = SIMILAR, AND in aqa Shang 10 а Sakei oats on 

"LIBRARY CACHE STATISTICS" of trace file, reloads of CRSR are greater than 500,000 the database. Any change to this setting should betestedto — 

Evidence Details: raar the extent of performance impacts for your application. 
References 


** In your Alert log, haring = SIMILAR, which high library reload : : 
DYQUD st og Gua e tenng мета сап Rae E расе NOTE:1169017.1 ANNOUNCEMENT: Deprecating the cursor sharing 


图 3-8 
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我 们 看 到 ， 这 个 工具 给 出 的 最 终 建议 是 设置 CURSOR SHARING-FORCE, ， 这 个 调整 虽然 
对 减少 ORA-4031 有 一 定 帮 助 ， 不 过 针对 这 个 案例 ， 显 然 是 不 够 全 面 的 。 工 具 可 以 解决 一 些 问 
题 ， 但 绝对 不 是 问题 的 全 部 。 虽 然 Oracle 提供 了 ORA-4031 的 诊断 工具 ， 但 是 诊断 结果 未 必 准 
确 ， 因 为 客户 的 系统 是 千差万别 的 ， 完 全 依赖 于 工具 是 不 可 取 的 。 在 很 多 情况 下 ， 我 们 仍然 需 


要 手工 分 析 。 
.. UM 


一 般 来 说 ， 分 析 ORA-4031 需要 从 ALERT LOG 和 TRACE 开始 ， 在 很 多 情况 下 ， 结合 
AWR/STATSPACK 报告 是 十 分 必要 的 。 我 们 还 是 从 上 面 的 那个 示例 看 起 ， 手 工分 析 一 下 ， 看 看 
fll ORACLE Metalink 工具 分 析 的 结果 有 何不 同 。 首 先 查 看 ALERT LOG: 


Wed Apr 30 15:09:37 2008 
Errors in file /u0l/app/oracle/admin/db10000/ bdump/ kf 2 cjq0 1618308.trc: 

ORA-00604: error occurred at recursive SQL level 1 

ORA- 04031: unable to allocate 4032 bytes of shared memory ("shared pool", "unknown 
object", "sga heap(2,0)","kglsim object batch") 

Wed Apr 30 15:09:37 2008 

Errors in file /u0l/app/oracle/admin/db10000/ bdump/kf2_j 000 1581468. гс: 

ORA- 00604: error occurred at recursive SQL level 1 

ORA- 04031: unable to allocate 4216 bytes of shared memory ("shared pool", "select 
ul.user#, u2.user#, u...","sga heap(2,0)","library cache") 

Failure to extend rollback segment 11 because of 4031 conditionFULL status of roll back 
segment 11 set 

Wed Apr 30 15:09:42 2008 

Errors in file /u0l/app/oracle/admin/db10000/ bdump/ kf 2 j 001 1565180.trc: 

ORA-00604: error occurred at recursive SQL level 1 

ORA- 04031: unable to allocate 4216 bytes of shared memory ("shared pool", "select 
ul.user#, u2.user#, u...","sga heap(2,0)", "library cache") 

Wed Apr 30 15:09:45 2008 
Errors in file /u0l/app/oracle/admin/db10000/ bdump/ kf 2 smon 1647004.trc: 
ORA-00604: error occurred at recursive SQL level 1 

ORA- 04031: unable to allocate 4216 bytes of shared memory ("shared pool", "unknown 
object", "sga heap(2,0)", "library cache" 
Wed Apr 30 15:09:46 2008 

Errors in file /u0l/app/oracle/admin/db10000/udump/kf2_ora_1048804.trc: 

ORA- 04031: unable to allocate 4032 bytes of shared memory ("shared pool", "unknown 
object", "sga heap(2,0)","kglsim object batch") 

Wed Apr 30 15:09:47 2008 
Errors in file /u0l/app/oracle/admin/db10000/ bdump/ kf 2 j 001 1565180.trc: 

ORA-00604: error occurred at recursive SQL level 2 

ORA- 04031: unable to allocate 4216 bytes of shared memory ("shared pool", "| 0B$","sga 
heap(2,0)","library cache") 
Wed Apr 30 15:09:52 2008 
Errors in file /u0l/app/oracle/admin/db10000/ bdump/ kf 2 j 000 1581468. гс: 

ORA- 00604: error occurred at recursive SQL level 1 

ORA- 04031: unable to allocate 4216 bytes of shared memory ("shared pool", "select 
ul.user#, u2.user#, u...","sga heap(2,0)", "library cache") 

Wed Apr 30 15:09:52 2008 
Errors in file /u0l/app/oracle/admin/db10000/ bdump/ kf 2 smon 1647004.trc: 
ORA-00604: error occurred at recursive SQL level 1 

ORA- 04031: unable to allocate 4216 bytes of shared memory ("shared pool", "unknown 
object", "sga heap(2,0)", "library cache" 
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Wed Apr 30 15:09:55 2008 
Shutting down Instance (abort) 
License high water mark = 151 
Instance terminated by USER, pid 


= 1048804 


这 个 系统 出 现 了 大 量 的 ORA-4031， 主 要 是 无 法 分 配 一 些 大 于 4KB 的 空间 ， 最 终 DBA 通过 
shutdown abort 强制 关闭 后 重启 了 系统 。 从 ALERT LOG 中 我 们 并 没有 发 现 更 多 有 价值 的 内 容 ， 


接 下 来 查看 TRACE 文件 : 
*** 2008-04-30 13:24:47.918 


*** SESSION 10: (19.1) 2008-04-30 13: 24: 47. 904 


The following information assists Oracle in diagnosing 
causes of ORA-4031 errors. This trace may be disabled 
by setting the init.ora parameter 4031 dump bitvec 


Current information setting: 006 


Dump Interval 2300 seconds SGA Heap Dump Interval 23600 seconds 


Last Dump Ti mez04/30/2008 13:24 


Allocation request for: kglsi т object 


Heap: 70000000004b848, size: 4032 


54f ff 


:46 


batch 


pk 


从 最 后 两 行 可 以 看 出 ， 在 分 配 kglsim 对 象 的 时 候 ， 无 法 分 配 4032B 的 连续 空间 ， 因 此 报错 。 


接 下 来 查看 共享 池 的 整体 情况 : 


Allocation Name Size 
"free memory" 29313288 
"miscellaneous" 12936120 
"transaction" 800448 
"UNDO INFO SEGMENTED ARRAY" 325056 
"errors" 23080 
"temporary tabl" 3136 
"SEQ S.0." 264800 
"partitioning d" 92400 
"db handles" 1740000 
"replication session stats" 503120 
"ges regular msg buffers" 1576248 
"table definiti" 116 
"PL/SQL MPCODE" 419304 
"gcs resource hash table" 2097152 
"PL/SQL DI ANA" 608352 
"trigger inform" 0 
"ges enqueues" 6563240 
"PL/SQL PPCODE" 0 
"ges resource hash table" 4325316 
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"trigger defini" 0 
"gcs resources" 45304256 
"sim memory hea" 2558400 
"dictionary cache" 1065728 
"db block hash buckets" 19589168 
"ges resources" 441539912 
"KQR M PO" 45568 
"Checkpoint queue" 5245440 
"library cache" 6486264 
"type object de" 0 
"sql area" 1229936 
"sessions" 1119456 
"gcs shadows" 28805632 
"event statistics per sess" 4696416 
"trigger source" 0 
"VIRTUAL CIRCUITS" 926800 
"KGLS heap" 517760 
"parameters" 34048 
"fixed allocation callback" 312 
Memory Utilization of Subpool 2 
Allocation Name Size 

"free memory" 7120752 
"miscellaneous" 31854176 
"PL/SQL DIANA" 327896 
"gcs resources" 45304256 
"Checkpoint queue" 5245440 
"sim memory hea" 2558400 
"PL/SQL PPCODE" 0 
"КОА S 50" 1952 
"PL/SQL MPCODE" 103384 
"ges enqueues" 6085384 
"ges resources" 441419824 
"FileOpenBl ock" 15431456 
"parameters" 0 
"joxs heap init" 1424 
"ges big msg buffers" 6770088 
"db block hash buckets" 2490368 
"enqueue" 3177816 
"gcs shadows" 28802536 
"temporary tabl" 6480 
"PLS non-lib hp" 2744 
"KGK heap" 32816 
"KCL name table" 7345992 
"dictionary cache" 2103808 
"partitioning d" 0 
"trigger inform" 0 
"KGLS heap" 29080 
"trigger source" 0 
"library cache" 7696608 
"processes" 1968000 
"sql area" 28072 
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"PL/SQL SOURCE" 0 
"KQR M PO" 156864 
"errors" 0 
"trigger defini" 0 
"event statistics per sess" 4685072 
"fixed allocation callback" 304 
"type object de" 0 
"table definiti" 0 


Allocation Name Size 
"free memory" 17748320 
"miscellaneous" 17136616 
"ges enqueues" 6542112 
"gcs shadows" 28803528 
"table definiti" 0 
"trigger source" 0 
"parameters" 0 
"sim memory hea" 2568592 
"KQR M PO" 184376 
"partitioning d" 0 
"errors" 0 
"PL/SQL MPCODE" 116192 
"ges reserved msg buffers ' 2096008 
"gcs resources" 45304480 
"KGLS heap" 7840 
"temporary tabl" 4240 
"ktlbk state objects" 975520 
"PL/SQL PPCODE" 0 
"MTTR advisory" 38448 
"KSXR pending messages que" 853952 
"KQR L PO" 151552 
"db block hash buckets" 19589184 
"dictionary cache" 1071104 
"ges resources" 441479424 
"enqueue resources" 1084528 
"PL/SQL SOURCE" 0 
"PX subheap" 30296 
"library cache" 6153192 
"KGK heap" 552 
"sql area" 76136 
"sessions" 1119456 
"trigger inform" 1624 
"event statistics per sess" 4696416 
"PL/SQL DIANA" 0 
"trigger defini" 0 
"Checkpoint queue" 5245440 
"fixed allocation callback" 328 
"VIRTUAL CIRCUITS" 900320 
Memory Utilization of Subpool 4 


34 共享 池 故 障 处 理 123 


Allocation Name Size 
"free memory" 6669520 
"miscellaneous" 20107808 
"KQR M PO" 8704 
"sim memory hea" 2560968 
"errors" 0 
"KQR L PO" 129024 
"KCL bast context freelist" 336000 
"session param values" 3621888 
"gcs resources" 60737168 
"transaction" 667040 
"table definiti" 0 
"PL/SQL DIANA" 40200 
"trigger defini" 0 
"KGLS heap" 26560 
"partitioning d" 0 
"MTTR advisory" 606000 
"parameters" 1064 
"trigger inform" 0 
"ges resources" 436017912 
"channel handle" 391504 
"trigger source" 0 
"ges enqueues" 6048136 
"dictionary cache" 33792 
"PL/SQL PPCODE" 0 
"gcs shadows" 44234316 
"KCL lock context" 364320 
"temporary tabl" 2504 
"library cache" 6557816 
"Temporary Tables State Ob" 389736 
"sql area" 42920 
"sessions" 1119456 
"PL/SQL MPCODE" 111424 
"event statistics per sess" 4696416 
"FileldentificatonBlock" 1153752 
"DML lock" 1529560 
"1M buffer" 528384 
"Checkpoint queue" 5245440 
"fixed allocation callback" 384 


可 以 看 出 ,这 个 系统 的 共享 池 分 为 4 个 子 池 ， 每 个 子 池 的 空 闪 内 存 容量 都 比较 大 , 最 大 的 有 
200 多 兆 字 节 ,最 小 的 有 60 多 兆 字 节 。 这 说 明 共 享 池 的 空闲 空间 充足 ， 只 是 碎片 化 比较 严重 。 从 
上 面 的 数据 我 们 看 到 库 缓 存 和 sql area 所 占 的 空间 其 实 并 不 大 ,这 一 点 可 以 说 明 ，MOS 分 析 给 出 
的 修改 CURSOR_SHARING 参数 的 方案 并 不 是 真正 的 核心 。 虽 然 调整 CURSOR_SHARING 可 以 
改善 共享 池 ， 但 是 其 根本 原因 并 不 在 这 里 。 从 ges resources 项 的 数据 中 可 以 看 出 一 些 比 较 异 常 的 
情况 。 在 每 个 子 池 中 ，ges resources 都 占用 了 440MB EA, 这 是 相当 大 的 。 这 是 一 套 ВАС 系统 ， 
ges resources 用 于 GLOBAL ENQUEUE SERVICE 相关 的 数据 结构 ， 一 般 情况 下 在 系统 启动 时 根 
据 m. locks 和 Im ress 参数 的 值 以 及 DB CACHE 的 大 小 确定 初始 化 分 配 的 容量 ,通常 为 几 十 兆 字 
节 。 当 这 种 数据 结构 不 够 用 的 时 候 , 会 自动 进行 动态 扩展 。 在 Oracle 9i 中 , 这 项 资源 的 扩展 方式 
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是 每 次 扩展 一 个 。 从 Oracle 10.2 开始 , 为 了 防止 这 种 扩展 方式 导致 共享 池 碎 片 化 , 算法 改 为 每 次 
扩展 一 组 ， 不 再 逐个 扩展 。ges resource 资源 是 PERMANENT 的 对 象 ， 扩 展 后 基本 不 会 释放 。 
此 如 果 ges resources 扩展 得 十 分 频繁 ， 就 会 在 共享 池 中 形成 很 多 不 可 释放 的 点 ， 从 而 将 共享 池 截 
断 为 多 个 小 块 ， 造 成 共享 池 碎 片 化 。 在 刚刚 重启 的 系统 中 ， 我 们 检查 了 рез resources 的 大 小 。 在 
4 个 子 池 中 ，ges resources 资源 总 计 为 100 EJF, XWH ges resources 的 扩展 十 分 频繁 , 这样 
就 可 能 导致 共享 池 由 于 ges resources 扩展 而 形成 大 量 的 碎片 。 因 此 初步 定位 为 ges resources 导致 
了 问题 。 想 要 在 9i 中 彻底 解决 这 个 问题 是 比较 困难 的 ， 而 在 10g 中 ,由 于 ges resources 扩展 算法 
的 优化 ， 这 种 问题 就 不 容易 出 现 了 。 不 过 在 9i 中， 可 以 通过 增加 共享 池 的 容量 ， 增 加 Im locks 
和 Im ress 参数 来 缓解 此 问题 。 调 整 参 数 后 ， 系 统 中 的 问题 确实 得 到 了 解决 。 

在 分 析 和 解决 ORA-4031 的 问题 时 , 最 主要 的 是 分 析 问 题 发 生 的 原因 ， 到底 是 由 于 共享 池 容 
量 不 足 还 是 由 于 共享 池 碎 片 化 。 如 果 共 享 池 的 空 闪 内 存 数量 很 小 , 那么 很 可 能 是 共享 池 容 量 不 足 
导致 ， 而 如 果 空 闲 内 存 比 较 大 ， 但 还 是 经 常会 出 现 ORA-4031， 那 么 共享 池 碎 片 化 导致 该 问题 的 
可 能 性 就 比较 大 了 。 这 种 情况 下 ， 查 看 每 个 对 象 的 大 小 , 确认 是 否 存 在 异常 是 十 分 关键 的 。 如 果 
能 够 找到 一 些 特别 之 处 ,我 们 就 可 以 根据 这 个 线索 往 下 追溯 ,从 而 定位 问题 的 关键 。 比 如 ， 如 果 
我 们 发 现 sql area 和 库 缓 存 所 占 的 空间 较 大 ， 那 么 就 可 以 分 析 如 何 减 少 它们 所 占 空间 的 大 小 ; 如 
果 我 们 发 现存 在 大 量 的 高 版 本 的 SQL， 那 么 将 CURSOR_SHARING 从 SIMILAR 修改 为 FORCE 
可 能 是 比较 好 的 方案 。 

如 果 ORA-4031 主要 是 因为 共享 池 设 置 偏 低 导 致 的 ,那么 扩大 共享 池 就 是 十 分 好 的 解决 方案 。 
可 能 很 多 DBA 认为 使 用 绑 定 变量 是 最 佳 的 解决 方案 ， 不 过 最 好 的 方案 往往 是 可 望 而 不 可 及 的 。 
修改 应 用 是 一 个 十 分 敏感 的 话题 ,也 意味 着 大 量 的 成 本 投入 ,能 够 通过 扩大 内 存 解决 的 问题 有 
可 能 修改 应 用 是 很 难 被 接受 的 。 

如 果 是 由 于 共享 池 雄 片 导致 的 ORA-4031 问题 , 那么 减少 子 池 的 数量 , 以 及 调整 使 用 保留 池 
的 最 小 分 配 内 存 参数 C 比如 从 默认 的 4400 调整 为 4000 ) 是 十 分 有 效 的 手段 。 

随 着 共享 内 存 自 动 管理 技术 和 内 存 自动 管理 技术 的 引入 以 及 内 存 价格 的 大 幅度 下 降 ， 
ORA-4031 这 个 问题 好 像 不 那么 款 手 了 。 由 于 共享 池 可 以 动态 地 自动 扩展 ， 因 此 即使 出 现 了 
ORA-4031, 也 不 会 引起 十 分 严重 的 问题 。 不 过 共享 内 存 自 动 管理 也 有 其 局 限 性 , 对 于 负载 很 高 ， 
或 者 负载 波动 十 分 频繁 的 系统 ， 如 果 SGA TARGET 设置 得 偏 低 ， 那 么 就 很 容易 出 现 SGA 
RESIZE。 在 业务 十 分 繁忙 的 时 候 出 现 较为 频繁 的 SGA RESIZE 会 严重 影响 SGA 的 性 能 ， 导 致 
游标 方面 的 争 用 ， 严 重 时 会 导致 系统 挂 起 。 因 此 如 果 想 要 使 用 共享 内 存 自动 管理 ， 那 么 首先 要 
确保 SGA TARGET 的 设置 是 充足 的 ， 甚 至 略 高 于 系统 最 高 负载 。 另 外 要 设置 共享 池 的 最 小 值 
(设置 SHARED_POOL_SIZE 参数 )， 这 样 才 能 确保 SGA 的 效率 不 会 因为 SGA RESIZE MAIK 
度 下 降 。 

虽然 在 共享 内 存 自动 管理 的 情况 下 ，ORA-4031 的 出 现 不 再 那么 危险 ， 不 过 经 常 监控 是 否 
存在 ORA-4031， 定 期 在 系统 较 空 闲 的 时 候 刷 新 一 下 共享 池 ， 对 于 共享 池 的 高 效 运作 还 是 很 有 
帮助 的 。 


34 ”共享 池 故 障 处 理 125 


3.4. ”其 他 共享 池 常 见 故障 
共享 池 响 应 速度 下 降 是 很 常见 的 共享 池 故 障 。 从 AWR 报告 中 ,我 们 经 常会 看 到 类 似 下 面 的 


Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class 
CPU ti me 10,018 18.3 

latch: library cache 3,200 880 215 6.9 Concurrency 
latch: shared pool 3,510 849 242 6.6 Concurrency 
latch free 1,186 305 251 2.4 Other 
db file sequential read 62,915 282 4 2.2 User 1/0 


在 上 面 的 示例 中 , 共享 池 相 关门 锁 的 总 等 待 时 间 虽 然 不 到 20%, 但 是 平均 等 待 时 间 却 超过 了 
200 毫秒 ， 而 这 些 门 锁 的 正常 等 待 时 间 应 为 几 毫 秒 ， 因 此 系统 的 性 能 会 受到 很 大 的 影响 。 在 这 种 
情况 下 ， 需 要 分 析 到 底 是 什么 原因 导致 了 这 个 问题 。 以 老 白 的 经 验 来 看 ， 导 致 类 似 问 题 的 可 能 性 
最 大 的 因素 包括 : 共享 池 过 小 ,共享 池 RESIZE 操作 ， 有 人 在 编译 重要 的 存储 过 程 或 者 视图 ， 碰 
到 了 Bug. 

共享 内 存 自动 管理 或 者 内 存 自动 管理 中 共享 池 RESIZE 操 作 频 繁 出 现 导致 类 似 问 题 的 可 能 性 
很 大 , 可 以 通过 查询 V$SGA_RESIZE_OPS 视图 来 进行 诊断 ， 下面 是 一 个 存在 共享 池 拌 动 的 典型 
案例 。 


COMPONENT OPER TY ОРЕК MODE START TI ME END TI ME TARGET 
DEFAULT buffer cache SHRINK EDI ATE 2009-08-25 11:01:19 2009-08-25 11:01:19 20528 
shared poo GROW EDIATE 2009-08-25 11:01:19 2009-08-25 11:01:19 1824 
DEFAULT buffer cache SHRINK EDI ATE 2009-08-25 11:01:39 2009-08-25 11:01:39 20512 
Streams poo GROW EDI ATE 2009-08-25 11:01:39 2009-08-25 11:01:39 48 
DEFAULT buffer cache SHRINK EDIATE 2009-08-25 11:01:41 2009-08-25 11:01:41 20496 
streams poo GROW EDIATE 2009-08-25 11:01:41 2009-08-25 11:01:41 64 
DEFAULT buffer cache SHRINK EDIATE 2009-08-25 11:01:47 2009-08-25 11:01:47 20480 
streams poo GROW EDIATE 2009-08-25 11:01:47 2009-08-25 11:01:47 80 
DEFAULT buffer cache SHRINK EDI ATE 2009-08-25 11:01:48 2009-08-25 11:01:48 20464 
streams poo GROW EDI ATE 2009-08-25 11:01:48 2009-08-25 11:01:48 96 
DEFAULT buffer cache SHRINK EDI ATE 2009-08-25 11:01:50 2009-08-25 11:01:50 20448 
streams poo GROW EDIATE 2009-08-25 11:01:50 2009-08-25 11:01:50 112 
DEFAULT buffer cache SHRINK EDI ATE 2009-08-25 11:01:53 2009-08-25 11:01:53 20432 
streams poo GROW EDI ATE 2009-08-25 11:01:53 2009-08-25 11:01:53 128 
DEFAULT buffer cache SHRINK EDI ATE 2009-08-25 11:01:57 2009-08-25 11:01:57 20416 
streams poo GROW EDI ATE 2009-08-25 11:01:57 2009-08-25 11:01:57 144 
DEFAULT buffer cache SHRINK EDI ATE 2009-08-25 11:01:58 2009-08-25 11:01:58 20400 
streams poo GROW EDI ATE 2009-08-25 11:01:58 2009-08-25 11:01:58 160 
DEFAULT buffer cache SHRINK EDI ATE 2009-08-25 11:01:59 2009-08-25 11:01:59 20384 
streams poo GROW EDIATE 2009-08-25 11:01:59 2009-08-25 11:01:59 176 
DEFAULT buffer cache SHRI NK EDI ATE 2009-08-25 11:02:00 2009-08-25 11:02:00 20368 
streams poo GROW EDIATE 2009-08-25 11:02:00 2009-08-25 11:02:00 192 
DEFAULT buffer cache SHRINK EDI ATE 2009-08-25 11:02:01 2009-08-25 11:02:01 20352 
Streams poo GROW EDIATE 2009-08-25 11:02:01 2009-08-25 11:02:01 208 
DEFAULT buffer cache SHRINK EDI ATE 2009-08-25 11:02:09 2009-08-25 11:02:09 20336 
streams poo GROW EDIATE 2009-08-25 11:02:09 2009-08-25 11:02:09 224 
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DEFAULT buffer cache SHRINK 
reams poo GROW 
EFAULT buffer cache SHRINK 
reams poo GROW 
EFAULT buffer cache SHRINK 
reams poo GROW 
EFAULT buffer cache SHRINK 
reams poo GROW 
EFAULT buffer cache SHRINK 
reams poo GROW 
EFAULT buffer cache SHRINK 
reams poo GROW 
EFAULT buffer cache SHRINK 
reams poo GROW 
reams poo GROW 
EFAULT buffer cache SHRINK 
reams poo GROW 
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为 了 避免 占用 过 多 篇 幅 ,， 老 白 省 去 了 大 部 分 的 数据 ， 800 行 。 不 过 从 这 些 数 


据 已 经 可 以 看 出 
共享 池 出 现 严重 的 性 能 问题 


除了 共享 池 拌 动 外 ， 还 有 一 个 经 党 出 现 的 问题 一 一 


情形 ， 最 常见 的 一 种 是 其 他 操作 都 很 正常 ， 只 是 对 某 张 表 的 操作 出 现 问题 ， 


‚ 在 3 分 钟 多 的 时 间 内 ，SGA 的 各 个 池 在 不 停 变化 , 这 


么 频繁 的 变化 肯 


共享 池 突 发 挂 起 现象 。 这 种 现象 包括 几 种 


-25 11:02:09 20320 
-25 11:02:09 240 
-25 11:02:10 20304 
-25 11:02:10 256 
-25 11:02:11 20288 
-25 11:02:11 272 
-25 11:02:12 20272 
25; 11502112 288 
-25 11:02:13 20256 
-25 11:02:13 304 
-25 11:02:20 20240 
-25 11:02:20 320 
-25 11:03:17 20224 
-25 11:03:17 336 
-25 11:03:20 352 
-25 11:03:20 20208 
-25 11:03:21 368 
定 会 导致 

哪怕 只 是 简单 的 


SELECT 操作 也 会 导致 挂 起 。 磁 到 这 种 情况 如 何 分 析 呢 ? 最 快捷 和 简单 的 方法 是 通过 

v$session wait 检查 会 话 在 等 待 什么 事件 。 比 较 合 理 的 做 法 是 ， 先 进行 HANGANALYZE 分 析 ， 

查看 到 底 系统 是 否 存 在 挂 起 现象 。 这 里 介绍 一 个 相关 的 案例 。 
一 个 客户 的 系统 突然 出 ee 现象 ， 


查 发 现 挂 起 的 会 话 都 在 等 待 行 


。 直 接 对 这 个 行 


系统 中 的 会 


话 数 突然 猛 增 。 


DBA 经 过 检 
锁 涉 及 的 表 执 行 SELECT 操作 也 会 导致 该 表 挂 


起 。 接 到 电话 后 , 老 白马 上 让 DBA бсн 3 级 的 HANGANALYZE 分 析 , 通 过 HANGANALYZE 


报告 我 们 发 现 : 


HANG ANALYSIS: 


Found 36 objects waiting for «sid/sess srno/proc ptr/ospid/wait event» 


«153/8226/0xbd414b0/25567/enqueue» 


Cycle 1: «sid/sess srno/proc ptr/ospid/wait event» 
«61/60457/0xbcd9640/29261]li brary cache lock» 


«153/8226/0xbd414b0/25567/enqueue» 
Open chains found: 
Chain 1: «sid/sess srno/proc ptr/osp 

<375/ 41785/0xbd13c10/ 29658] о Wai 
Chain 2 : «sid/sess srno/proc ptr/osp 

«491/62836/0xbd6cbd0/7054/No Wait» 
Chain 3 : «sid/sess srno/proc ptr/osp 


«676/34256/0xbd71300/13956/No Wait» 


Chain 4 : «sid/sess srno/proc ptr/osp 
«743/13745/0xbd55720/16135/SQL* Ne 
Other chains found 


d/wait event» 
> 
d/wait event» 
d/wait event» 


d/wait event» 


break/reset to client» 
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Chain 5 : «sid/sess srno/proc ptr/ospid/wait event» 
<47/12295/0xbd0be70/29623/library cache pin» 
Chain 6 : «sid/sess srno/proc ptr/ospid/wait event» 
«68/4549/0xbd1b150/29707/library cache lock» 

- «620/14459/0xbd844b0/6103/library cache lock» 
-- «299/29643/0xbd7adf0/7060/library cache lock» 
Chain 7 : «sid/sess srno/proc ptr/ospid/wait event» 
«89/35994/0xbd44b20/6461/library cache lock» 

- «620/14459/0xbd8445b0/6103/library cache lock» 
-- «299/29643/0xbd7adf0/7060/library cache lock» 
Chain 8 : «sid/sess srno/proc ptr/ospid/wait event» 

«116/2726/0xbd1b9b0/29711/library cache lock» 

- «620/14459/0xbd844b0/6103/library cache lock» 
-- «299/29643/0xbd7adf0/7060/library cache lock» 
Chain 9 : «sid/sess srno/proc ptr/ospid/wait event» 

«131/62101/0xbd85140/6201/enqueue» 
Chain 10 : «sid/sess srno/proc ptr/ospid/wait event» 
«135/42351/0xbd19c60/29699/library cache lock» 
- «620/14459/0xbd8445b0/6103/library cache lock» 
«299/29643/0xbd7adf0/7060/library cache lock» 


为 了 节省 篇 幅 , 此 处 略 去 了 分 析 结 果 的 后 半 部 分 , 不 过 前 面部 分 已 经 足够 让 我 们 完成 这 次 分 
析 了 。 首 先 可 以 看 到 : 


Found 36 objects waiting for «sid/sess srno/proc ptr/ospid/wait event» 
«153/8226/0xbd414b0/25567/enqueue» 


SID=153 的 会 话 在 等 待 enqueue， 而 有 36 个 其 他 的 会 话 在 等 待 这 个 会 话 持 有 的 资源 。 

似乎 一 切 都 很 简单 ， 我 们 已 经 发 现 了 问题 的 “元 Xl”"， 在 这 种 情况 下 ， 是 不 是 杀 掉 153 号 会 
话 就 能 够 解决 问题 了 呢 ? 答案 当然 是 否定 的 ， 一 名 优秀 的 DBA 绝对 不 会 这 样 做 ， 我 们 必须 继续 
往 下 分 析 HANGANALYZE 报告 。 


Cycle 1 : «sid/sess srno/proc ptr/ospid/wait event» 
«61/60457/0xbcd9640/29261/library cache lock» 
- «153/8226/0xbd414b0/25567/enqueue» 


无 论 如 何 , Cycle 是 必须 分 析 的 , 因为 Cycle 往往 是 能 够 找到 问题 根源 的 地 方 。 Cycle 1 的 “ 受 
害 者 ”是 153 号 会 话 ， 也 就 是 阻塞 了 36 SAIN “TCM”, m 153 号 会 话 在 等 待 enqueue, XA 
euqneue 却 被 61 号 会 话 所 持 有 ,而 61 号 会 话 正 在 等 待 library cache lock。 我 们 在 HANGANALYZE 
报告 中 检查 了 一 遍 , 并 没有 会 话 阻 塞 61 号 会 话 。 在 这 种 情况 下 , 如 果 是 很 紧急 的 生产 系统 故障 ， 
那么 杀 掉 61 号 会 话 , 看 系统 能 否 恢复 是 比较 简单 的 处 理 方法 。 而 如 果 我 们 要 去 追寻 问题 的 根源 
所 在 ,就 需要 继续 分 析 ， 这 时 系统 状态 转 储 是 十 分 有 用 的 。 不 过 在 一 个 特别 重要 的 生产 系统 中 ， 
可 能 不 允许 我 们 进行 系统 状态 转 储 ， 这 样 就 无 法 进一步 分 析 问 题 的 原因 。 比 如 上 例 中 ， 我 们 征 
询 了 客户 的 意见 ， 然 后 做 了 一 个 LEVEL 266 的 系统 状态 转 储 ， 发 现 SESSION 61 在 等 待 一 个 
library cache lock， 而 这 个 library cache lock 正 被 自己 持 有 ， 这 是 典型 的 自 死 锁 现象 。 于 是 我 们 
立即 杀 掉 SESSION 61 (从 HANGANALYZE 报告 中 可 以 看 到 这 个 会 话 的 OSPID 是 29261), fif 
决 了 这 个 问题 。 
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共享 池 的 问题 极为 复杂 , 不 是 短 短 的 几 节 内 容 就 能 够 涵盖 的 。 除 了 共享 池内 存 不 足 和 碎片 化 

这 两 个 最 为 典型 的 问题 , 大 多 数 情 况 下 共享 池 出 现 问题 是 由 于 游标 共享 或 者 并 发 访问 某 个 共享 池 
对 象 引起 的 。 下 面 的 几 篇 Metalink 文档 对 于 分 析 共 享 池 问 题 有 很 好 的 帮助 ， 建 议 大 家 仔细 阅读 ， 
HMA o 
Q) Troubleshooting Library Cache: Lock, Pin and Load Lock [ID 444560.1] 
口 Troubleshooting: "WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! " [ID 
278316.1] 
口 Troubleshooting: High Version Count Issues [ID 296377.1] 
口 How to Determine the Blocking Session for Event: "cursor: pin S waiton X” [ID 786507.1] 
О Troubleshooting "library cache: mutex X” waits. [ID 1357946.1] 
Q How To Troubleshoot ORA-4031’s and Shared Pool Issues With Procwatcher (Doc ID 
1352623.1) [ID 1355030.1] 
Q) Troubleshooting: Tuning the Shared Pool and Tuning Library Cache Latch Contention [ID 
62143.1] 
О Troubleshooting: Waits for Mutex Type Events [ID 1377998.1] 
О Troubleshooting: Tuning the Shared Pool and Tuning Library Cache Latch Contention [ID 

62143.1] 


3.5 ”共享 池 优 化 的 主要 思路 


共享 池 的 优化 要 从 几 个 方面 去 考虑 : 首先 是 共享 池 本 身 的 配置 ,其 次 是 游标 的 共享 ,然后 是 
缓解 共享 池 的 碎片 ， 最 后 是 分 析 Bug 和 补丁 。 

共享 池 配 置 主要 是 看 共享 池 的 容量 是 否 足 够 。10 多 年 前 ，DBA 管理 共享 池 是 十 分 痛苦 的 ， 
由 于 物理 内 存 总 是 无 法 满足 应 用 系统 的 需要 ,因此 总 是 无 法 分 配给 共享 池 足 够 的 空间 , 我 们 必须 
想 尽 一 切 办 法 来 减少 应 用 对 共享 池 的 使 用 , 从 而 使 更 多 的 并 发 访问 能 够 尽 可 能 地 对 共享 池 产 生 最 
小 的 影响 。 而 共享 池 管 理 总 是 希望 某 个 字典 缓存 或 者 库 缓 存 能 够 在 共享 池 中 存储 更 多 的 时 间 。 在 
目前 的 硬件 条 件 下 , 物理 内 存 几乎 是 无 极限 的 ( 由 于 内 存 的 廉价 和 服务 器 可 配置 内 存 总 量 的 大 幅 
提升 )， 因 此 我 们 总 是 可 以 给 共享 池 分 配 足够 的 空间 ， 从 而 保证 共享 池 的 高 效 运作 。 在 现 阶段 来 
看 ， 保 持 共享 池 配 置 有 足够 的 空间 是 共享 池 优化 工作 中 十 分 重要 的 一 点 。 

在 共享 池 的 配置 中 , 子 池 的 数量 也 是 一 个 十 分 重要 的 因素 。 在 11g 版 本 之 前 ,共享 池 子 池 的 
最 小 值 偏 小 ， 而 由 于 目前 多 核 CPU 的 广泛 使 用 , 使 得 Oracle 识别 的 逻辑 CPU 总 数 很 多 ， 基 于 每 
4 个 CPU 分 配 一 个 子 池 的 原则 , 很 容易 自动 分 配 较 多 的 子 池 。 如 果 共 享 池 偏 小 , 而 且 碎片 化 比较 
严重 ， 那 么 减少 子 池 的 数量 ， 使 每 个 子 池 不 小 于 256MB 甚至 512MB 是 十 分 必要 的 。 

在 游标 共享 方面 , 尽 可 能 使 用 绑 定 变量 是 非常 重要 的 。 共 享 游标 可 以 减少 大 量 的 共享 池 空 间 ， 
减少 共享 池 中 游标 的 总 数量 ， 从 而 减少 共享 池 的 争 用 。 通 过 使 用 绑 定 变量 和 良好 的 SQL 书写 风 
格 可 以 增加 游标 的 共享 。 如 果 应 用 程序 未 使 用 绑 定 变量 , 我 们 也 可 以 通过 将 CURSOR_SHARING 
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参数 设置 为 FORCE 或 者 SIMILAR 来 加 强 游标 的 共享 ,很 多 专家 都 建议 使 用 CURSOR_SHARING 
=FORCE， 而 不 建议 使 用 SIMILAR。 这 是 因为 SIMILAR 可 能 出 现 另 外 的 问题 ， 使 某 个 游标 出 现 
大 量 不 能 共享 的 子 游标 。 实 际 上 FORCE 也 有 其 自身 的 问题 , 如 果 某 条 SQL 在 参数 不 同时 需要 使 
用 不 同 的 执行 计划 ， 那 么 使 用 了 FORCE 之 后 ， 就 存在 问题 了 (在 11g 版 本 中 由 于 ACS 的 出 现 ， 
这 个 问题 已 经 得 到 了 很 明显 的 改善 ), 某 些 SQL 执行 计划 的 错误 相 比 共享 池 中 的 游标 不 能 共享 来 
说 ， 可 能 具有 更 大 的 危害 ， 在 这 方面 我 们 需要 做 好 权衡 。 

基于 上 述 原 因 , 老 白 建议 在 11g 之 前 的 版 本 中 , 还 是 通过 适当 地 使 用 绑 定 变量 来 解决 游标 的 
共享 问题 。 在 某 些 需 要 根据 柱状 图 的 不 同 而 采用 不 同 执行 计划 的 情况 下 , 尽 可 能 不 使 用 绑 定 变量 。 
而 对 于 lg 版 本 的 系统 ， 尽 可 能 使 用 绑 定 变量 吧 (在 使 用 时 要 注意 ， 如 果 存 在 较 多 SQL 版 本 ， 
可 能 是 碰 到 了 ACS 的 Bug )。 

游标 共享 可 以 减少 硬 解 析 的 数量 ,， 从 而 缓解 共享 池 相 关 争 用 。 在 有 些 情况 下 , 调用 的 次 数 很 
多 ， 从 而 导致 接 件 的 数量 很 大 ， 达 到 每 秒 几 千 甚至 上 万 。 在 这 种 情况 下 ,减少 软 解析 也 是 十 分 关 
键 的 ， 通 过 加 大 OPEN_CURSORS 和 SESSION_CACHED_CURSORS 参数 ， 尽 可 能 保持 热点 游 
标 处 于 开放 和 缓存 状态 ,减少 软 解析 的 数量 ， 可 以 有 效 地 缓解 共享 池 的 性 能 问题 , 加 大 系统 并 发 
处 理 能 力 。 

如 果 共 享 池 碎 片 化 十 分 严重 ， 就 需要 了 解 碎片 产生 的 原因 ， 从 根本 上 解决 问题 。 如 果 和 暂时 无 
法 找到 问题 的 根源 , 也 可 以 通过 定期 在 业务 较 小 的 时 候 手 工 刷新 共享 池 来 保持 共享 池 的 效率 , 减 
少 由 于 共享 池 碎 片 化 而 导致 的 性 能 问题 。 为 了 缓解 碎片 化 的 问题 ， 将 一 些 重 要 的 PL/SQL 对 象 和 
SQL 保留 在 共享 池 中 也 是 十 分 有 效 的 方法 。 特 别 是 一 些 较 大 的 PL/SQL 对 象 , 每 次 数据 库 重启 后 ， 
通过 DBMS SHARED POOL.KEEP 存储 过 程 将 其 保留 在 共享 池 中 ， 可 以 减少 这 些 大 型 对 象 重新 
加 载 的 次 数 ， 从 而 缓解 其 加 载 过 程 对 共享 池 的 影响 。 

为 了 减少 共享 池 产 生性 能 问题 , 在 业务 高 峰 期 尽 可 能 不 要 修改 表 结构 也 是 十 分 重要 的 , 在 业 
务 高 峰 期 进行 表 和 索引 的 修改 、 授 权 等 操作 ， 可 能 导致 共享 内 存 中 大 量 的 游标 失效 ， 从 而 产生 大 
量 的 硬 解 析 ， 严 重 时 其 至 会 导致 挂 起 。 

从 10g 版 本 开始 , 由 于 共享 内 存 自动 管理 的 引入 ,共享 池 的 优化 工作 也 简化 了 许多 ， 只 要 设 
置 足够 大 的 SGA_TARGET 参数 ,共享 内 存 就 可 以 被 Oracle 自动 管理 了 。 不 过 使 用 共享 内 存 自 动 
管理 (或 者 11g 版 本 的 内 存 自 动 管理 ) 也 不 能 一 劳 永 逸 地 解决 共享 池 问 题 。 在 某 些 情况 下 ， 如 果 
SGA TARGET 不 足 ， 共 享 内 存 可 能 出 现 抖动 ， 从 而 造成 严重 的 共享 池 问 题 。 因 此 在 使 用 共享 内 
存 自动 管理 时 不 能 太 过 简单 ， 除 了 设置 SGA_TARGET 外 ， 还 需要 设置 共享 池 的 
SHARED POOL SIZE 参数 。 通 过 该 参数 ,设置 共享 池 的 最 小 值 ， 将 这 个 值 设置 得 足够 大 ， 可 以 
确保 共享 池 不 会 由 于 SGA 拌 动 而 出 现 严 重 的 性 能 问题 。 

另外 很 多 共享 池 的 性 能 问题 是 由 于 Bug 引起 的 , 在 安装 数据 库 的 时 候 , 尽 可 能 用 最 新 的 补丁 
4E ,减少 由 于 Bug 导 致 问题 的 可 能 性 .不 过 安装 最 新 的 补丁 包 并 不 等 于 高 枕 无 优 , 定 期 分 析 ALERT 
LOG, 分 析 AWR 报告 ， 及 时 发 现 新 的 问题 是 十 分 必要 的 。 


理解 控制 文件 


控制 文件 是 Oracle 数据 库 中 一 个 十 分 重要 的 文件 , 虽然 这 个 文件 不 大 , 而且 访问 它 的 VO 量 
也 不 是 很 大 , 但 是 这 个 文件 中 却 包含 了 整个 数据 库 的 结构 。 控 制 文件 中 的 信息 包含 数据 库 、 数 据 
文件 .CHECKPOINT REDO LOG 及 归档 日 志 信息 和 RMAN 备份 的 信息 。 这 些 信 息 对 于 数据 库 
是 十 分 重要 的 ， 对 于 数据 库 实例 恢复 、 介 质 恢复 等 都 具有 关键 的 作用 。 

如 果 控 制 文件 出 现 故 障 ， 可 能 导致 数据 库 无 法 正常 打开 ，Oracle 数据 库 通 过 多 个 控制 文件 
副本 的 方式 来 实现 控制 文件 的 高 可 用 性 。Oracle 对 这 些 控制 文件 副本 采用 并 行 写 的 方式 ， 所 有 
的 控制 文件 操作 都 在 一 个 逻辑 的 控制 文件 事务 中 完成 对 所 有 控制 文件 副本 的 更 新 。 只 需 将 这 些 
控制 文件 副本 存储 在 不 同 的 文件 系统 或 者 磁盘 上 ， 即 使 某 个 文件 系统 或 者 磁盘 出 现 故障 ， 也 不 
会 损坏 所 有 的 控制 文件 ， 只 要 有 一 个 控制 文件 的 副本 是 可 用 的 ， 我 们 就 可 以 用 这 个 副本 来 打开 
数据 库 。 

由 于 控制 文件 并 行 写 是 通过 一 个 逻辑 事务 完成 的 ， 在 一 个 逻辑 事务 中 有 多 个 物理 WO， 因 此 
当 系 统 宕 掉 的 时 候 ， 可 能 会 出 现 这 种 情况 : 某 个 控制 文件 操作 在 一 个 控制 文件 中 已 经 完成 ,而 男 
一 个 控制 文件 和 这 个 控制 文件 不 一 致 。 这 种 情况 下 , 会 出 现 控 制 文件 损坏 的 现象 。 我 们 只 要 用 完 
好 的 控制 文件 覆盖 损坏 的 控制 文件 ， 就 可 以 解决 问题 了 。 


4.1 控制 文件 的 内 部 结构 


控制 文件 相对 较为 简单 ， 所 以 大 家 对 控制 文件 内 部 结构 的 研究 也 较为 透彻 ， 在 网 络 上 有 
大 量 关 于 控制 文件 结构 的 资料 ， 一 般 来 说， 了 解 了 这 些 资料 ， 就 足以 支撑 DBA 的 日 常 维护 工 
TET. 

本 节 重 点 关注 控制 文件 事务 方面 的 技术 细节 ， 对 于 那些 METALINK 和 网 络 上 介绍 较 多 的 控 
制 文件 内 部 数据 项 只 做 简单 的 介绍 。 


4.1.1. 控制 文件 和 控制 文件 事务 

控制 文件 分 为 文件 头 和 内 容 两 部 分 。 文 件 头 包含 控制 文件 块 大 小 、 控 制 文件 包含 的 数据 块 数 
量 这 些 信息 。 在 加 载 数 据 库 的 时 候 ， 启 动 进程 会 读 取 控制 文件 的 头 块 ， 并 进行 校 验 。 如 果 校 验 失 
败 ， 数 据 库 会 报错 。 在 Oracle 106 之 前 ， 控 制 文件 的 块 大 小 一 般 为 4096B， 从 10g 版 本 开始 ， 控 
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制 文件 的 块 大 小 被 扩大 为 16KB。 

控制 文件 中 保存 的 最 为 重要 的 数据 是 整个 数据 库 的 结构 , 包括 所 有 的 数据 文件 、 在 线 日 志文 
件 等 ,因此 控制 文件 是 数据 库 能 够 正常 打开 的 关键 。 如 果 控 制 文件 损坏 , 那么 RDBMS 就 无 法 知 
道 数据 库 所 属 文件 的 位 置 以 及 数据 文件 的 状态 ， 数 据 库 也 就 无 法 正常 工作 。 

控制 文件 的 更 新 操作 实际 上 有 一 些 类 似 于 事务 的 特点 ， 有 些 操作 必须 一 起 完成 或 者 一 起 失 
败 。 而 针对 控制 文件 的 操作 是 不 适合 使 用 类 似 普通 事务 的 方式 的 , 因此 针对 控制 文件 事务 也 需要 
一 套 机 制 来 确保 其 完整 性 。 而 且 在 数据 库 实例 突然 宕 机 或 者 操作 控制 文件 的 进程 出 现 故 障 的 时 
йк, 需要 有 一 套 机 制 来 确保 被 中 断 的 操作 不 会 损坏 控制 文件 里 的 数据 项 。 控制 文件 的 操作 采用 了 
较为 简单 的 方法 ， 通 过 一 个 CF 锁 来 进行 排他 操作 。 如 果 要 进行 控制 文件 事务 ， 那 么 就 需要 持 有 
CF 锁 的 排他 模式 ， 从 而 避免 并 发 的 同类 操作 。 对 于 读 操作 ， 只 需要 共享 的 CF 锁 ， 因 此 两 个 并 行 
的 读 操 作 是 可 以 同时 进行 的 。 

控制 文件 的 前 部 包含 一 个 数据 库 信息 的 记录 ， 这 个 记录 大 概 在 210B 左右 〈 不 同 的 数据 库 版 
本 可 能 略 有 不 同 )， 不 过 这 些 信息 还 是 占用 了 一 个 独立 的 控制 文件 块 。 控 制 文件 这 样 的 处 理 方式 
降低 了 控制 文件 事务 的 操作 复杂 度 , 因为 一 个 独立 的 控制 文件 库 可 以 通过 一 个 独立 的 原子 操作 来 
完成 修改 ， 这 种 设计 也 就 简化 了 错误 恢复 。Oracle 为 了 实现 控制 文件 事务 的 故障 回 滚 , 设计 了 一 
种 很 巧妙 的 算法 。 所 有 的 控制 文件 信息 都 是 双 份 存储 的 ,任何 一 个 逻辑 记录 都 有 两 个 物理 的 副本 。 
其 中 的 一 个 副本 是 当前 副本 , 也 就 是 当前 正在 使 用 的 副本 ; 而 另外 一 个 副本 是 旧 副 本 或 者 正在 进 
行 修改 还 没 提 交 的 副本 。 在 控制 文件 的 数据 库 信息 记录 里 保存 了 一 个 控制 位 图 信息 , 用 以 记录 哪 
个 副本 是 当前 正在 起 效 的 副本 。 如 果 要 读 取 控制 文件 的 信息 , 会 话 必 须 首 先 读 取 版 本 控制 位 图 确 
定 哪个 物理 块 是 当前 的 ， 然 后 再 去 读 取 这 个 数据 。 

当 会 话 要 去 修改 某 个 数据 的 时 候 ， 首 先 需 要 以 排他 模式 获取 CF 锁 ， 这 样 就 避免 了 其 他 会 话 
同时 修改 控制 文件 。 获 得 CF 锁 后 ， 会 话 首先 会 修改 非 当 前 的 数据 块 的 信息 ， 修 改 完成 后 ， 通 过 
一 个 原子 操作 将 控制 位 图 信息 中 的 当前 块 信息 更 新 ， 这 样 修改 就 完成 了 。 

如 果 一 个 修改 操作 需要 修改 某 个 控制 文件 块 中 的 多 个 记录 ,那么 Oracle 会 首先 将 这 些 修改 存 
储 在 一 个 缓冲 区 中 ， 等 数据 组 织 完成 后 , 一 起 写 入 控制 文件 ， 从 而 提高 写 的 效率 。 根 据 上 面 的 算 
法 , 每 个 控制 文件 事务 至 少 需要 4 个 串 行 的 IO 操作, 如 果 存 在 多 个 控制 文件 副本 , 那么 这 些 IO 
操作 有 一 半 会 以 异步 VO 的 方式 进行 ,如 果 系 统 不 支持 异步 VO ,那么 VO 操作 的 数量 会 成 倍增 加 。 
而 如 果 一 个 控制 文件 事务 要 修改 多 个 控制 文件 块 中 的 数据 ，LO 的 数量 就 更 大 了 。 所 以 说 控制 文 
件 事务 是 一 种 UO 敏感 的 操作 ， 如 果 控 制 文件 存放 在 性 能 不 好 的 存储 上 ， 那 么 控制 文件 方面 的 锁 
等 待 将 会 很 严重 。 从 这 一 点 可 以 看 出 , 我 们 以 前 的 一 些 观点 是 错误 的 。 以 往 我 们 认为 控制 文件 的 
读 写 量 很 小 ， 因 此 可 以 将 它们 存放 在 VO 性 能 相对 较 差 的 存储 设备 上 ,在 了 解 了 控制 文件 事务 的 
特点 后 ， 就 不 会 再 这 样 处 理 了 。 如 果 存 储 控制 文件 的 设备 IO REME, IA CF 锁 等 待 将 会 对 
系统 的 性 能 造成 影响 。 

视图 V$CONTROLFILE_RECORD_SECTION 包含 了 所 有 的 控制 文件 结构 。 这 个 视图 是 对 内 
部 数据 结构 X$KCCRS 中 存储 信息 的 重新 整理 。 相 关 示 例如 下 : 
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AME RSLBN RSRSZ RSNUM RSNUS RSI OL RSILW RSRLW 
DATABASE 1 192 1 0 0 0 
CKPT PROGRESS 2 4084 4 0 0 0 0 
REDO THREAD 4 104 1 0 0 0 
REDO LOG 5 12 5 3 0 0 3 
DATAFILE 6 180 100 11 0 0 145 
FI LENAME 9 524 116 15 0 0 0 
TABLESPACE 17 68 100 12 0 0 12 
TEMPORARY FILENAME 18 56 100 1 0 0 1 
RMAN CONFI GURATI ON 19 1108 50 0 0 0 0 
LOG HI STORY 26 36 226 28 1 28 28 
OFFLINE RANGE 21 56 145 0 0 0 0 
ARCHI VED LOG 28 584 13 4 1 4 4 
BACKUP SET 29 40 204 0 0 0 0 
BACKUP PIECE 30 136 210 0 0 0 0 
BACKUP DATAFILE 49 116 211 0 0 0 0 
BACKUP REDOLOG 52 16 107 0 0 0 0 
DATAFILE COPY 53 660 210 0 0 0 0 
BACKUP CORRUPTION 70 44 185 0 0 0 0 
COPY CORRUPTI ON 11 40 204 0 0 0 0 
DELETED OBJECT 12 20 408 0 0 0 0 
PROXY COPY 13 852 210 0 0 0 0 
RESERVED4 96 36 226 0 0 0 0 

97 216 1 1 0 0 0 

98 56 145 1 1 1 1 


通过 上 面 的 结果 ， 读 者 可 以 了 解 控制 文件 中 的 主要 内 容 、 控 制 文 件 中 包含 数据 库 的 信息 、 
CKPT 的 信息 、REDOLOG 的 信息 、 数 据 文件 的 信息 、 表 空间 的 信息 以 及 日 志 切 换 历史 信息 。 除 
此 之 外 ， 控 制 文件 中 还 包含 RMAN 备份 的 CATALOG 信息 。 通 过 对 上 述 信 息 的 分 析 ， 我 们 可 以 
T fit RMAN 在 不 使 用 恢复 目录 数据 库 的 时 候 ， 是 如 何 把 信息 存储 在 控制 文件 中 的 。 
CHECKPOINT 的 进度 信息 也 会 被 保存 在 控制 文件 中 ， 而 且 CHECKPOINT 是 发 生 频率 很 高 
的 操作 。 如 果 更 新 CHECKPOINT 进度 信息 也 需要 使 用 控制 文件 事务 ,那么 CKPT 进程 将 会 成 为 
CF 锁 的 长 期 持 有 者 ,这样 就 增加 了 系统 由 于 CF 锁 冲 突 而 挂 起 的 可 能 性 , 因此 CHECKPOINT 信 
息 的 修改 不 使 用 控制 文件 事务 机 制 .CHECKPOINT 进度 记录 占用 了 一 个 控制 文件 块 的 一 半 容 量 ， 
因此 Oracle 为 每 个 数据 库 实例 分 配 一 个 独立 的 物理 块 来 记录 CHECKPOINT 进度 记录 。 和 普通 的 
控制 文件 块 不 同 ，CHECKPOINT 进度 记录 使 用 单一 的 物理 块 来 记录 数据 。 这 样 的 机 制 使 
CHECKPOINT 进度 的 写 入 可 以 作为 一 个 原子 操作 ， 进 行 该 操作 时 ， 不 会 影响 其 他 数据 。 


41.2 ”控制 文件 自动 扩展 


在 控制 文件 中 , 如 果 已 经 存在 的 数据 要 重新 写 入 新 的 内 容 , 那么 Oracle 数据 库 会 重用 这 个 记 
录 。 大 多 数控 制 文件 记录 都 可 以 循环 使 用 ,比如 RMAN CATALOG 的 信息 和 LOG 历史 信息 ,Oracle 
通过 一 个 初始 化 参数 control_file_record_keep_time 来 设 定 控制 文件 中 的 数据 至 少 保存 多 少 天 才能 
够 被 重用 ， 它 的 默认 值 是 7。 这 个 参数 可 以 控制 的 控制 文件 记录 包括 一 系列 周期 性 的 数据 : LOG 
HISTORY, OFFLINE RANGE, ARCHIVED LOG, BACKUP SET, BACKUP PIECE, BACKUP 
DATAFILE , BACKUP REDOLOG , DATAFILE COPY , BACKUP CORRUPTION , COPY 
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CORRUPTION, DELETED OBJECT 和 PROXY COPY. 

如 果 所 有 的 空闲 记录 都 已 经 写 满 了 ， 但 是 最 旧 的 记录 还 没有 保存 到 参数 设 定 的 天 数 ， 那 么 
Oracle 会 动态 扩展 记录 节 的 大 小 《如 果 控 制 文件 不 足以 提供 记录 节 扩 展 所 需要 的 空间 ,控制 文件 
也 会 动态 扩展 )， 每 个 记录 节 的 最 大 记录 数 是 65535， 因 此 控制 文件 动态 扩展 时 不 能 超过 这 个 限 
制 。 控 制 文件 的 大 小 也 有 一 定 的 限制 , 控制 文件 的 大 小 受到 块 版 本 位 图 大 小 的 限制 ,由 于 块 版 本 
位 图 都 很 大 ， 这 个 限制 一 般 很 难 达到 。 如 果 控 制 文件 进行 了 动态 扩展 , 那么 在 ALERT LOG 中 会 
出 现 一 些 kccrz 的 信息 。 要 避免 这 种 扩展 ， 可 以 将 上 述 参数 设置 为 0。 另外 这 个 参数 还 设置 了 这 
些 周 期 性 数据 保存 的 最 小 时 间 周 期 ， 因 此 如 果 使 用 控制 文件 来 存放 RMAN 的 CATALOG 信息 ， 
那么 在 设置 这 个 参数 时 要 十 分 注意 。 必 须 设 置 足够 大 的 参数 ， 以 保证 所 有 的 RMAN 恢复 所 需要 
的 信息 都 是 完整 的 。 如 果 这 个 参数 设置 为 5， 而 一 次 数据 库 全 备 的 时 间 间 隔 为 7 天 ,那么 在 做 数 
据 库 恢复 的 时 候 ， 就 可 能 找 不 到 关于 上 一 次 全 备 的 信息 ， 导 致 恢复 失败 。 

控制 文件 扩展 是 一 种 十 分 危险 的 操作 ， 需 要 通过 CF 锁 排 斥 其 他 的 控制 文件 操作 ， 直 到 扩展 
结束 。 如 果 这 时 相关 的 会 话 失效 或 者 数据 库 实例 宕 机 ,那么 控制 文件 就 有 可 能 被 破坏 ,这 种 情况 
下 ， 只 能 通过 备份 的 控制 文件 来 恢复 了 。 从 这 一 点 也 可 以 看 出 控制 文件 备份 的 重要 性 ， 另 外 要 尽 
可 能 地 防止 控制 文件 的 自动 扩展 , 因此 在 创建 数据 库 时 , 设 定 足 够 大 的 DB_FILES 等 参数 是 十 分 
必要 的 。 虽 然 控制 文件 能 自动 扩展 , 但 我 们 应 该 尽 可 能 事先 通过 参数 的 控制 来 减少 这 种 扩展 ， 以 
达到 最 高 的 安全 性 。 


4.1.8. 如何 转 储 和 分 析 控 制 文件 


如 果 要 研究 控制 文件 ， 就 需要 转 储 控 制 文件 ，Oracle 提供 了 一 个 事件 CONTROLF 来 实现 控 
制 文件 的 转 储 。 这 个 命令 很 简单 ， 我 们 可 以 用 oradebug 来 操作 转 储 。 
sqlplus '/аѕ sysdba' 


SQL»oradebug setmypi d; 
SQL»oradebug dump controlf 3; 


这 样 操作 ， 一 个 转 储 文件 就 会 生成 在 用 户 dump 目录 了 。 如 果 不 习 惯 使 用 oradebug， 也 可 以 
使 用 alter session 命令 来 执行 : 
alter session set events 'immediate trace name controlf level 3'; 


这 里 ， 老 白 使 用 了 级 别 为 3 的 转 储 ， 关 于 级 别 的 描述 见 表 4-1。 


表 4-1 
Dump Level Dump 内 容 
1 仅仅 文件 头 
2 文件 头 、 数 据 库 信息 记录 ，ckpt 进 程 记录 
3 所 有 的 记录 类 型 ， 不 过 对 于 循环 的 记录 类 型 ， 仅 仅 转 储 最 早 和 最 后 的 记录 
4 同上 ， 再 加 上 循环 记录 类 型 的 最 新 4 条 记录 
5+ 同上 ， 不 过 转 储 更 多 的 循环 记录 类 型 记录 
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EP fe qu qe 


| 文件 


下 面 通过 一 


个 示例 来 介绍 控制 文件 中 包含 的 内 容 。 


LERE EEEE EEEE EEEE EEEE EEEE EEE EE EEEE EEE EEEE EEE EEEE EEE EEEE EEE EEEE EEE EEEE EEE EEEE: 


DATABASE ENTRY 


米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 


09/26/2011 15:24:40 
DB Name "ORCL" 

Database flags = 0х 
Controlfile Creatio 
ncmplt recovery sc 
Resetlogs scn: 


Prior resetlogs scn 


Redo Version: compa 


size = 316, compat 
last-recid= 0, old- 
extent = 1, blkno 


size = 316, section max = 1, 
recno = 0, last-recno = 0) 
= 1, numrecs = 1) 


00404000 0x00001000 
n Timestamp 
n: 0x0000. 00000000 


ti ble=0xa200400 


09/26/2011 15:24:40 


0x0000.000716f7 Resetlogs Ti mestamp 
0x0000.00000001 Prior resetlogs Ti mestamp 


section in-use = 1, 


09/26/2011 15:25:38 


#Data files = 4, s$0nline files = 4 
Database checkpoint: Threadzl scn: 0x0000.0086f261 
Threads: #Enabled=1, #Open=1, Head=1, Tail-l 
Max log members = 3, Max data members = 1 
Arch list: Head=0, Tail=0, Force scn: 0x0000.008e2e00scn 
Activation 10: 1290675138 
Controlfile Checkpointed at scn: 
thread:0 rba:(0x0.0.0 
上 面 是 数据 库 信 息 AM. vi 
CHECKPOINT Mi à 


02/17/2008 01:50:35 


0x0000.000716f7 


0x0000.008f79dc 04/09/2012 13:13:35 


， 这 部 分 的 大 小 是 316B ， 包 含 了 DB МАМЕ 等 信息 。 下 面 的 小 节 


米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 


CHECKPOI NT PROGRESS RECORDS 


米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 


section in-use = O, 


THREAD £1 - 
low cache rba:(Oxffffff 
on di 
reset 
hear 
THREAD £2 
low cache rba:(0x0.0.0) 
0x0000.00000000 01/01/1988 00:00:00 
0x0000.00000000 01/01/1988 00:00:00 


on di 
reset 
hear 


H 


= 8180, 
last-recid= 0, 
[extent = 1, blkno 

status: 0 


(size compa 


sk scn: 0x0000. 
ogs scn: 
beat: 779018961 


status: 0 


sk scn: 
ogs scn: 
beat: 0 mount i 


默认 情况 下 , k— tu 6 


old- 


t size = 8180, sectio 
recno = 0, last-recn 
= 2, numrecs = 11 
x2 flags:0x0 dirty:0 
f.ffffffff.ffff) 
008f9f3e 03/09/2012 1 
1306171311 
lags: 0х0 dirty:0 
on disk rba: (0x0. 


mount id: 
x0 


d: 0 


n max = 11, 


0 = 0) 


on disk rba:(0x1c3.118fa. 0) 


9:30:56 


0x0000.000716f7 09/26/2011 15:25:38 


0.0) 


8 个 THREAD 的 CHECKPOINT 信息 小 节 ， 


合计 8180B。 为 了 节省 


篇 幅 ， 老 白 只 列 出 了 其 中 两 个 。 由 于 本 数据 库 是 单 实例 的 ， 所 以 THREADS. 的 信息 都 是 0。 
low cache rba, on disk rba 和 on disk scn resetlogs scn 等 信息 。 可 以 看 
现在 已 经 写 盘 的 数据 是 2012 年 3 月 9 日 19 点 


CHECKPOINT 的 信息 
出 ， 这 
30 分 56 秒 的 数据 。 当 CHECKPOINT 发 生 的 时 候 ，j 

由 于 篇 幅 所 限 ， 余 下 的 TRACE 文件 老 白 就 不 一 一 介 


包含 
个 数据 库 2011 年 9 


月 26 日 做 过 resetlogs, 


一 个 控制 文件 ， 转 储 文件 比较 容易 理解 。 


这 些 数 据 会 
绍 了 ， 有 兴趣 的 朋友 可 以 淮 


被 更 新 。 


试 自己 转 储 
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414 文件 头 和 控制 文件 信息 
大 家 都 知道 ， 控 制 文件 中 包含 文件 的 信息 ， 比 如 ， 包 含 FILE#=1 文件 的 信息 : 


DATA FILE #1: 

(name #7) /opt/oracle/oradata/orcl/system0l. dbf 

creation size=0 block size=8192 status=Qxe head=7 tail=7 dup=l 
tablespace 0, index=1 krfil=1 prev_file=0 

unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00 
Checkpoint cnt: 541 scn: 0x0000.008ef 261 04/08/2012 15:53:12 

Stop scn: Oxffff.ffffffff 03/20/2012 07:26:24 

Creation Checkpointed at scn: 0х0000. 00000007 02/17/2008 01:50:54 
thread:0 rba:(0x0.0.0) 

Offline scn: 0x0000.000716f6 prev range: 0 

Online Checkpointed at scn: 0x0000.000716f7 09/26/2011 15:25:38 
thread:1 rba:(0x1.2.0) 

Hot Backup end marker scn: 0x0000.00000000 

aux file is NOT DEFINED 


部 分 信息 可 以 通过 VSDATAFILE 视图 查看 到 。 实 际 上 这 个 视图 的 信息 也 是 从 控制 文件 中 
二 只 要 数据 库 处 于 MOUNT 状态 ， 控 制 文件 打开 后 就 可 以 获取 这 个 视图 的 信息 。 

在 数据 库 中 还 有 一 个 视图 一 一 V$DATAFILE_HEADER， 和 V$DATAFILE 不 同 的 是 ， 这 个 视 
图 是 从 数据 文件 的 文件 头 中 提取 的 ， 能 够 反映 出 数据 文件 的 情况 。 一 般 来 说 ， 这 两 个 视图 中 的 
CHECKPOINT_CHANGE# 应 该 是 基本 上 一 致 的 ， 如 果 我 们 发 现 V$DATAFILE 中 的 
CHECKPOINT_CHANGE# 大 于 V$DATAEFILE_ HEADER 中 的 ， 那 么 说 明 数 据 文件 需要 恢复 。 

如 果 要 从 备份 集中 恢复 数据 库 , 一 般 来 说 , 恢复 过 来 的 数据 文件 的 文件 头 中 ,SCN 都 会 小 于 
控制 文件 中 记录 的 文件 的 SCN ( 这 是 因为 数据 文件 的 备份 往往 早 于 控制 文件 的 备份 )， 完 成 数据 
文件 的 恢复 后 ， 可 以 利用 归档 日 志 将 数据 文件 前 深 到 控制 文件 中 所 记录 的 SCN 的 位 置 。 如 果 准 
备 做 非 完 全 恢复 ,那么 我 们 可 能 会 恢复 到 某 个 SCN ,这 种 情况 下 ,如 何 判断 此 时 OPEN DATABASE 
RESETLOGS 是 否 会 成 功 呢 ?通过 检查 VSDATAFILE HEADER 就 可 以 找到 答案 


SQL> set line 200 
SQL» select fuzzy, status, error, recover, checkpoint change#, checkpoint ti me, 
count(*) 

2 from v$datafile header 

3 group by fuzzy, status, error, recover, checkpoint change£s, checkpoint time ; 


FUZ STATUS ERROR REC CHECKPOINT_CHANGE# CHECKPOIN COUNT( *) 


NO ONLINE 9529285 09-APR-12 4 
如 上 例 所 示 ， 所 有 的 文件 的 FUZZY 都 是 NO， 说 明 此 时 OPEN DATABASE RESETLOGS 是 
安全 的 。 如 果 查 询 得 到 的 结果 与 下 面 的 信息 类 似 : 
FUZ STATUS ERROR REC CHECKPOINT_CHANGE# CHECKPOI NT_ COUNT( * 


NO ONLINE 5311260 31-AUG- 2011 6 
YES ONLINE 5311260 31-AUG- 2011 1 
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那么 说 明 有 一 个 文件 是 不 一 致 的 ,可 能 需要 多 次 恢复 才能 达到 一 致 性 的 点 。 接 下 来 ,我 们 可 
以 通过 下 面 的 SQL 找 出 处 于 FUZZY 状态 的 文件 : 

Select name from v$datafile header where fuzzy=' YES 

如 果 这 个 文件 不 是 一 般 的 数据 文件 ， 而 是 系统 表 空 间 ， 那 么 该 数据 库 可 能 处 于 不 一 致 状态 ， 
重 置 日 志 会 失败 ， 因 此 需要 继续 恢复 下 一 个 日 志 。 如 果 不 太 走运 ， 下 一 个 日 志 已 经 丢失 了 ,那么 
可 能 就 无 法 通过 正常 的 OPEN RESETLOGS 打开 这 个 数据 库 。 这 时 通过 使 用 隐 含 参数 也 许可 以 强 
制 打开 数据 库 , 但 是 可 能 会 引发 一 些 其 他 问题 , 比如 , 出 现 ORA-600[4XXX] 或 者 ORA-600[2662] 
之 类 的 错误 。 关 于 这 方面 的 处 理 方法 ， 老 白 在 其 他 章节 已 有 所 介绍 ， 这 里 就 不 多 讨论 了 。 
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控制 文件 的 故障 主要 集中 在 文件 丢失 、 损 坏 方面 ， 男 外 ，CF 锁 冲 突 可 能 导致 数据 库 出 现 挂 
起 等 问题 ， 这 也 是 需要 DBA 密切 关注 的 。 


4.2.1 丢失 或 者 损坏 控制 文件 的 处 理 方法 


控制 文件 损坏 可 能 导致 数据 库 实例 故障 ， 因 此 DBA 必须 掌握 控制 文件 损坏 的 处 理 方法 。 单 
个 控制 文件 损坏 是 比较 容易 恢复 的 ， 因 为 一 般 的 数据 库 系 统 ， 控 制 文 件 都 不 止 一 个 ,而 且 所 有 的 
控制 文件 都 互 为 镜像 ， 只 要 复制 一 个 完好 的 控制 文件 蔡 换 已 损坏 的 控制 文件 就 可 以 了 。 控制 文件 
损坏 所 导致 的 最 典型 的 问题 就 是 启动 数据 库 出 错 ， 不 能 加 载 数据 库 。 


SQL»startup 
ORA- 00205: error in identifying controlfile, check alert log for more info 


查看 报警 日 志文 件 ， 有 如 下 信息 : 


alter database mount 

Mon May 14 13:59:51 2010 

ORA-00202: controlfile: 'D:\oracle\oradata\orcl\control0l.ctl' 
ORA- 27041: unable to open file 

05D-04002: unable to open file 

0/5-Еггог: (OS 2) 系统 找 不 到 指定 的 文件 。 


遇 到 这 种 情况 ， 需 要 首先 关闭 数据 库 实 例 。 

SQL>shutdown abort 

由 于 数据 库 根 本 就 没有 加 载 ， 所 以 shutdown abort 是 十 分 安全 的 。 关 闭 数 据 库 实 例 后 ， 需 要 
复制 一 个 完好 的 控制 文件 替换 已 损坏 的 控制 文件 ， 或 修改 init.ora 中 的 控制 文件 参数 ， 取 消 已 损 
坏 的 控制 文件 ， 然 后 重启 数据 库 。 

恢复 单个 控制 文件 是 比较 简单 的 ， 因为 数据 库 中 所 有 的 控制 文件 都 是 镜像 的 , 只 需要 简单 地 
复制 、 蔡 换 就 可 以 了 。 这 也 是 我 们 建议 在 不 同 磁盘 上 镜像 控制 文件 的 主要 原因 ， 如 果 磁 盘 故 障 导 
致 了 某 个 控制 文件 损坏 ， 只 要 还 有 一 个 控制 文件 是 完好 的 ， 就 可 以 进行 恢复 。 

如 果 所 有 的 控制 文件 都 损坏 了 怎么 办 呢 ? 这 种 情况 下 ,就 需要 使 用 备份 的 控制 文件 了 。 如 果 


H 
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比较 幸运 ， 系 统 有 备份 , 那么 只 要 将 备份 取出 ， 就 可 以 恢复 了 。 基 于 这 样 的 原因 , 老 白 建议 多 做 


控制 文件 的 备份 ， 长 期 保留 一 份 由 ALTER DATABASE BACKUP CONTROL FILE TO TRACE = 


生 的 控制 文件 的 文本 备份 每 次 新 增 数据 文件 后 都 重新 备份 一 次 )。 


上 面 我 们 讨论 的 是 一 些 比 较 理想 的 场景 。 在 茶 些 情况 下 , 我 们 可 能 不 够 走运 ， 当 有 多 个 控制 
文件 损坏 了 , 或 者 人 为 删除 了 所 有 的 控制 文件 , 通过 控制 文件 的 复制 已 经 不 能 解决 问题 时 


要 重新 建立 控制 文件 。 同 时 应 注意 ，ALTER DATABASE BACKUP CONTROL FILE TO 
可 以 产生 一 个 控制 文件 的 文本 备份 。 

以 下 是 重新 创建 控制 文件 的 详细 步骤 。 

(1) 关闭 数据 库 。 

SQL>shutdown immediate 

(2) 删除 所 有 控制 文件 ， 模 拟 控制 文件 丢失 。 

(3) 启动 数据 库 ， 出 现 错误 ， 且 不 能 启动 到 加 载 状 态 下 。 


SQL>startup 
ORA-00205: error in identifying controlfile, check alert log for more info 


查看 报警 日 志文 件 ， 有 如 下 信息 : 


SQL>alter database mount 
Mon May 26 11:53:15 2003 
ORA-00202: controlfile: 'D:Oracleoradatachencontrol01.ctl' 
ORA- 27041: unable to open file 
05D- 04002: unable to open file 
0/5-Error: (05 2) 系统 找 不 到 指定 的 文件 。 


(4) 关闭 数据 库 。 


SQL>shutdown immediate 


TRACE 


(5) 在 internal 或 sys 下 运行 创建 控制 文件 的 脚本 ， 注 意 完 整地 列 出 联机 日 志 及 数据 文件 的 路 
径 。 此 外 ， 也 可 以 修改 由 ALTER DATABASE BACKUP CONTROL FILE TO TRACE 备份 控制 文 


件 时 产生 的 脚本 ， 去 掉 多 余 的 注释 即 可 。 


STARTUP NOMOUNT 

CREATE CONTROLFILE REUSE DATABASE "TEST" NORESETLOGS NOARCHI VELOG 
AXLOGFILES 32 

AXLOGMEMBERS 2 

AXDATAFILES 254 

AXI NSTANCES 1 

AXLOGHI STORY 226 


GROUP 1 'D: ORACLEORADATATESTREDOO1.LOG' SIZE 1M 
GROUP 2 'D: ORACLEORADATATESTREDOO2.LOG' SIZE 1M 
GROUP 3 'D: ORACLEORADATATESTREDO03.LOG' SIZE 1M 
DATAFILE 

' D: ORACLEORADATATESTSYSTEMO1. DBF' 

' D: ORACLEORADATATESTRBSO1. DBF' 

' D: ORACLEORADATATESTUSERSO1. DBF' 
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' D: ORACLEORADATATESTTEMPO1. DBF' 
' D: ORACLEORADATATESTTOOLSO1. DBF' 
' D: ORACLEORADATATESTI NDX01. DBF' 
CHARACTER SET ZHS16GBK 
- Recovery is required if any of the datafiles are restored backups 
- Or if the last shutdown was not normal or immediate. 
RECOVER DATABASE 
--if the last shutdown was not normal or immediate 
--noarchi ve 
- RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE 
--archive 
- RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL 
- Database can now be opened normally. 
ALTER DATABASE OPEN; 
--if recover database until cancel 
-- ALTER DATABASE OPEN RESETLOGS 


(6) 如 果 没 有 错误 ， 数 据 库 将 启动 到 打开 状态 下 。 

上 面 介绍 了 重建 控制 文件 的 方法 。 重 建 控制 文件 用 于 恢复 全 部 控制 文件 的 损坏 , 需要 注意 其 
书写 的 正确 性 , 保证 包含 了 所 有 的 数据 文件 与 联机 日 志 。 我 们 在 启动 数据 库 之 前 , 一 定 要 确保 所 
有 的 数据 文件 都 已 经 被 包含 在 重建 的 控制 文件 脚本 中 了 。 如 果 在 编辑 过 程 中 误 删 了 某 个 文件 ， 当 
数据 库 打 开 后 ,要 想 再 将 其 加 入 到 数据 库 中 ， 就 需要 恢复 这 个 数据 文件 ， 否则 无 法 使 该 数据 文件 
处 于 在 线 状 态 。 但 如 果 丢 失 了 归档 日 志 ， 这 个 文件 可 能 就 无 法 再 次 加 入 到 数据 库 中 了 。 

在 做 数据 库 恢 复 时 ,我们 经 常会 碰 到 这 样 一 种 情况 : 因为 某 个 磁盘 损坏 了 , 不 能 再 恢复 或 存 
储 数 据 文 件 到 这 个 磁盘 ， 而 在 存储 到 其 他 磁盘 时 ， 就 必须 重新 创建 控制 文件 ,用 于 识别 这 个 新 的 
数据 文件 。 这 时 也 可 以 用 上 述 方法 进行 恢复 。 

下 面 来 看 一 个 更 为 极端 的 情况 : 丢失 了 所 有 的 控制 文件 及 备份 控制 文件 , 同时 没有 保存 记录 
文件 。 这 种 情况 下 该 如 何 处 理 呢 ? 比 较 麻烦 ,我们 需要 根据 系统 中 的 文件 或 者 裸 设备 , 手工 编写 
创建 控制 文件 的 命令 。 当 然 ， 也 可 以 从 其 他 类 似 的 系统 中 复制 一 份 文件 来 改写 。 只 要 足够 仔细 ， 
没有 遗漏 任何 文件 ,也 可 以 达到 目的 。 无论 我 们 是 否 采用 这 种 最 为 极端 的 方式 来 解决 问题 , 老 白 
都 希望 大 家 把 工作 做 在 前 面 ， 尽 可 能 避免 以 这 种 方式 来 进行 恢复 。 


4.2.2 ”控制 文件 的 优化 


在 一 般 情 况 下 , 控制 文件 的 变更 较 小 , 不 会 对 系统 的 性 能 产生 很 大 影响 。 由 于 控制 文件 的 IO 
EDA, 并 发 访问 量 也 不 会 很 大 , 所 以 由 于 IO 性 能 问题 导致 控制 文件 出 现 问题 的 可 能 性 十 分 小 。 
控制 文件 的 性 能 问题 往往 体现 在 控制 文件 锁 CF 方面 。 如 果 在 某 些 情况 下 我 们 发 现 CF 锁 等 待 十 
分 严重 ， 那 么 可 能 就 是 控制 文件 出 现 了 问题 。 

如 果 СЕ 锁 等 待 十 分 严重 , 很 多 情况 下 会 导致 数据 库 实例 宕 掉 , 或 者 需要 重启 实例 才能 彻底 
解决 问题 。 导 致 CF 锁 的 问题 往往 不 是 控制 文件 本 身 ， 因 此 要 防止 CF 锁 出 现 问题 ， 就 要 从 CF 
锁 的 使 用 者 来 考虑 。 一 般 来 说 ， 可 能 导致 CF 锁 冲 突 的 原因 主要 是 REDO LOG 切换 频率 过 快 、 
CKPT 过 于 频繁 或 归档 日 志 出 现 故障 。 因 此 还 是 要 从 这 几 个 角度 去 考虑 预防 CF 锁 冲 突 的 方法 ， 
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而 不 能 仅仅 从 控制 文件 本 身 去 考虑 。 使 用 适当 的 DB CACHE( 不 要 过 小 )、 确 保 LOG FILE SYNC 
响应 时 间 、 避 免 过 于 频繁 的 日 志 切 换 、 确 保 DATAGUARD 接收 处 于 正常 状态 等 都 是 较为 有 效 的 
方法 。 

另外 , 控制 文件 扩展 时 也 会 持 有 CF 锁 。 创 建 数据 库 时 要 设置 足够 大 的 参数 , 比如 DB_FILES 
等 ， 这 样 可 以 尽 可 能 减少 控制 文件 的 扩展 ， 进 而 减少 控制 文件 扩展 导致 的 问题 。 


理解 REDO 日 志 


REDO 日 志文 件 是 Oracle 数据 库 中 十 分 重要 的 文件 , 它 记 录 了 Oracle 的 所 有 变化 , 是 Oracle 
数据 库 能 够 正常 运行 、 不 丢失 数据 的 最 根本 保证 。 

REDO 日 志文 件 的 安全 性 是 首先 要 得 到 保证 的 ， 因 为 一 旦 REDO 日 志文 件 出 现 故 障 或 者 丢 
A, 可 能 导致 数据 丢失 , 数据 库 出 现 不 一 致 甚至 无 法 打开 等 重大 事故 。 另外, REDO 日 志 是 Oracle 
数据 库 中 访问 最 频繁 、 写 IO 最 多 的 文件 ， 因 此 其 访问 性 能 对 于 数据 库 整 体 性 能 提升 影响 很 大 。 

本 节 将 从 介绍 REDO 日 志 内 部 结构 开始 ， 和 大 家 一 起 讨论 REDO 日 志 相关 的 一 些 维护 、 优 
化 问题 。 


5.1 什么 是 REDO 日 志 


REDO 日 志文 件 是 Oracle 数据 库 实 例 恢 复 机 制 中 最 为 关键 的 组 成 部 分 REDO 日 志 机 制 的 目 
的 就 是 确保 数据 库 实 例 或 者 服务 器 发 生 故 障 时 , ANS CHR EAE, 不 会 丢失 已 经 提交 的 数据 。 
Oracle 为 了 实现 这 个 目标 ， 将 数据 库 的 变化 数据 记录 在 REDO 日 志文 件 中 ， 而 且 通 过 
Redo-Write-Ahead ( RWA ) 机 制 确保 数据 库 被 变更 之 前 ， 其 变更 的 REDO 日 志 信息 必须 先 写 人 日 
志 组 冲 区 ， 而 事务 提交 之 前 也 必须 首先 将 日 志 缓 冲 中 和 这 个 事务 相关 的 REDO 信息 写 人 REDO 
日 志文 件 。 

采用 这 个 机 制 ，Oracle 就 可 以 确保 在 数据 库 宕 机 后 ， 只 要 重新 启动 实例 ， 数据库 中 没有 被 及 
时 写 和 人 数据 文件 的 DB Cache 信息 和 一 些 不 一 致 的 未 提交 的 事务 信息 会 被 正确 恢复 ， 而 且 数据 库 
可 以 恢复 到 宕 机 前 的 一 致 性 状态 。 

REDO 日 志 被 设计 为 多 个 组 ， 一 个 数据 库 可 以 包含 多 个 REDO 日 志 组 。 这 样 设计 的 好 处 是 ， 
当 一 组 REDO 日 志 完 后 , 可 以 切换 到 另外 一 组 上 面 继续 写 ， 因此 不 需要 马上 清除 当前 REDO 日志 
中 的 信息 。 因 为 由 于 某 些 数据 块 的 写 盘 操作 还 没完 成 ， 这 些 信 息 有 可 能 还 不 能 马上 清除 ， 和 否则 数 
据 库 宕 机 后 就 没 法 完全 恢复 了 。 对 于 多 实例 的 数据 库 来 说 ， 每 个 实例 都 有 自己 独立 的 REDO 日 志 
组 ， 这 样 的 设计 确保 了 多 实例 数据 库 КЕРО 日 志 的 写 性 能 ， 因 为 不 同 实 例 不 需要 并 发 写 入 同一 组 
REDO 日 志 ， 从 而 避免 了 争 用 。 不 过 这 种 设计 使 得 实例 恢复 更 为 复杂 ， 因 为 所 有 实例 的 REDO 日 
志 中 的 变化 (CHANGE) 都 是 严格 排序 的 ， 并 且 是 不 会 跳跃 的 ， 实 例 恢复 所 需要 的 变化 可 能 
RELA REDO 日 志文 件 中 ， 因 此 恢复 时 无 法 像 单 实例 那样 只 根据 REDO 日 志 的 顺序 往 下 处 理 ， 
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而 要 不 停 地 在 多 个 实例 的 REDO 日 志 中 挑选 所 需要 的 变化 ， 从 而 顺序 地 应 用 所 有 变化 。 

REDO 日 志文 件 是 十 分 关键 的 ， 因此 和 控制 文件 一 样 ，Oracle 也 支持 对 REDO 日 志文 件 进行 
镜像 ， 我 们 可 以 设置 一 个 日 志 组 的 文件 数量 为 2 或 者 更 多 。 不 过 一 般 来 说 ,设置 为 2 就 足够 了 ， 
太 多 的 文件 会 增加 大 量 的 WO， 影 响 系统 性 能 。 使 用 REDO 日 志 镜 像 时 ， 最 好 能 够 将 不 同 的 文件 
放置 在 不 同 的 VG 上 ,甚至 不 同 的 磁盘 组 中 ， 当 然 放 置 在 不 同 的 存储 区 是 最 安全 的 。 如 果 我 们 使 
用 ASM， 那 么 把 这 些 文件 放 到 不 同 的 磁盘 组 中 是 很 好 的 选择 。Oracle 建议 将 两 个 文件 中 的 一 个 
放 在 数据 磁盘 组 中 ， 另 一 个 放 在 闪 回 磁盘 组 (Flashback Diskgroup ) 中 。 如 果 将 两 个 REDO 日 志 
文件 都 放 在 同一 个 VG 或 者 文件 系统 中 , 虽然 也 能 起 到 一 定 的 容错 作用 , 但 是 如 果 VG 故障 或 者 
文件 系统 故障 ， 我 们 将 失去 所 有 的 文件 ， 从 而 导致 一 些 不 可 恢复 的 故障 出 现 。 


5.2 REDO 的 基本 原理 


了 解 REDO 日 志 的 基本 原理 是 很 多 DBA 的 心愿 ,虽然 关于 REDO 日 志 内 部 原理 的 资料 很 多 ， 
但 都 过 于 零散 ， 而 且 REDO 日 志 本 身 十 分 复杂 ， 想 要 深入 了 解 其 内 部 算法 确实 比较 困难 。 老 白 
和 大 家 一 样 ,只 能 依靠 从 零散 的 技术 资料 中 获取 的 信息 进行 分 析 和 学 习 。 本 节 的 主要 目的 就 是 总 
结 这 些 学 习 成 果 ， 并 分 享 给 大 家 。 


5.2.1 介质 恢复 和 实例 恢复 的 基本 概念 


REDO 日 志 是 Oracle 为 确保 已 经 提交 的 事务 不 会 丢失 而 建立 的 一 种 机 制 。 实 际 上 ，REDO H 
志 的 存在 是 为 两 种 场景 准备 的 ， 一 种 我 们 称 为 实例 恢复 (Instance Recovery )， 另 一 种 称 为 介质 恢 
Я (Media Recovery )。 实例 恢复 的 目的 是 在 数据 库 发 生 故障 时 , 确保 数据 块 缓 冲 区 中 的 数据 不 会 
丢失 ,不 会 造成 数据 库 的 不 一 致 。 介 质 恢 复 的 目的 是 当 数 据 文件 发 生 故 障 时 ,能够 恢复 数据 。 虽 
然 这 两 种 恢复 使 用 的 机 制 类 似 ， 但 是 存在 本 质 的 不 同 ， 这 一 点 也 是 很 多 РВА 经 常会 混 消 的 。 

REDO 日 志 的 数据 是 按照 线程 来 组 织 的 。 对 于 单 实例 系统 来 说 ， 只 有 一 个 线程 ,而 对 于 КАС 
系统 来 说 ， 可 能 存在 多 个 线程 ， 每 个 数据 库 实 例 拥 有 一 组 独立 的 REDO 日 志文 件 ， 以 及 独立 的 
日 志 缓冲 区 ， 某 个 实例 的 变化 会 被 独立 记录 到 一 个 线程 的 REDO 日 志文 件 中 。 

对 于 介质 恢复 和 实例 恢复 来 说 ， 第 一 个 步骤 都 是 通过 REDO 日 志 的 信息 进行 前 滚 。 在 做 前 
滚 时 ， 通 过 REDO 日 志文 件 里 记录 的 数据 库 变 化 矢量 ( 稍 后 我 们 会 详细 地 介绍 数据 库 变 化 矢量 
CV ), 根据 SCN 的 比 对 ， 提 交 到 相关 的 数据 文件 上 ， 从 而 使 数据 文件 的 状态 向 前 滚动 。 大 家 要 
注意 的 是 ，UNDO 表 空 间 的 变化 也 被 记录 到 REDO 日 志 里 了 ， 因 此 UNDO 表 空 间 相 关 的 数据 文 
件 也 会 被 前 滚 。 当 前 滚 到 最 后 一 个 可 用 的 REDO 日 志 或 者 归档 日 志 时 ， 所 有 的 数据 库 恢 复 层面 
的 工作 就 全 部 完成 了 。 这 个 时 候 , 数据 库 包 含 了 所 有 的 被 记录 的 变化 , 这 些 变化 中 有 些 是 已 经 提 
交 的 ， 而 有 些 是 尚未 提交 的 。 在 最 新 状态 的 UNDO 表 空 间 中 ， 我 们 也 可 以 看 到 一 些 尚 未 提交 的 
事务 。 

因此 数据 库 下 一 步 需要 做 的 就 是 事务 层面 的 处 理 ， 回 滚 那些 尚未 提交 的 事务 ， 以 确保 数据 库 
的 一 致 性 。 
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对 于 单 实例 的 系统 , 实例 恢复 一 般 是 在 数据 库 实例 异常 故障 后 数据 库 重 启 时 进行 ， 当 数据 库 
执行 了 SHUTDOWN ABORT 命令 或 者 由 于 操作 系统 、 主 机 等 原因 宕 机 重启 后 ， 在 ALTER 
DATABASE OPEN 时 ， 就 会 自动 进行 实例 恢复 。 而 在 КАС 环境 中 ， 如 果 某 个 实例 宕 掉 了 ,活着 
的 实例 将 会 接管 ， 兰 宕 掉 的 实例 做 实例 恢复 。 除 非 是 所 有 的 实例 都 宕 掉 了 ， 这 样 的 话 ， 第 一 个 执 
fT ALTER DATABASE OPEN 的 实例 将 会 做 实例 恢复 。 这 也 是 REDO 日 志文 件 作为 实例 私有 的 组 
件 必须 存放 在 共享 存储 上 的 原因 。 

Oracle 数据 库 的 高 速 缓存 机 制 是 以 性 能 为 导向 的 。 高 速 缓存 机 制 应 该 最 大 限度 地 提高 数据 库 
的 性 能 ， 因 此 缓存 被 写 人 数据 文件 时 总 是 尽 可 能 推迟 。 这 种 机 制 大 大 提高 了 数据 库 的 性 能 , 但 是 
当 实例 出 现 故障 时 ， 可 能 存在 一 些 问 题 。 

首先 , 可 能 某 些 事物 对 数据 文件 的 修改 并 没有 完全 写 人 磁盘 , 或 者 磁盘 文件 中 丢失 了 某 些 已 
提交 事务 对 数据 文件 的 修改 信息 。 其次, 可 能 某 些 还 没有 提交 的 事务 对 数据 文件 的 修改 已 经 被 写 
人 磁盘 文件 了 。 也 有 可 能 某 个 原子 变更 有 一 部 分 数据 已 经 被 写 入 文件， 而 另外 一 部 分 数据 还 没有 
被 写 人 磁盘 文件 。 实 例 恢复 就 是 要 通过 ONLINE REDO LOG 文件 中 记录 的 信息 ， 自 动 完成 上 述 
数据 的 修复 工作 。 这 个 过 程 是 完全 自动 的 ， 不 需要 人 工 干预 。 

在 这 个 机 制 里 ， 有 两 个 问题 需要 解决 。 第 一 个 是 如 何 确保 已 经 提交 的 事务 不 会 丢失 , 第 二 个 
是 如 何在 数据 库 性 能 和 实例 恢复 所 需要 的 时 间 上 做 出 平衡 , 既 确 保 数 据 库 性 能 不 会 下 降 , 又 保证 
实例 恢复 可 以 快速 进行 。 

解决 第 一 个 问题 比较 简单 。Oracle 有 一 个 机 制 ， 叫做 Log-Force-at-Commit， 就 是 说 ,在 事务 
提交 时 ， 和 这 个 事务 相关 的 REDO 日 志 数 据 ， 包 括 COMMIT 记录 ， 都 必须 从 日 志 缓冲 区 中 写 人 
REDO 日 志文 件 ， 此 时 事务 提交 成 功 的 信号 才能 发 送 给 用 户 进 程 。 通 过 这 种 机 制 ， 哪 怕 已 经 提交 
的 事务 中 的 部 分 缓冲 缓存 还 没有 被 写 人 数据 文件 就 发 生 了 实例 故障 , 在 做 实例 恢复 的 时 候 , 也 可 
以 通过 REDO 日 志 的 信息 将 不 一 致 的 数据 前 滚 。 

Oracle 是 通过 CHECKPOINT 机 制 来 解决 第 二 个 问题 的 。 在 Oracle 数据 库 中 ， 对 缓冲 缓存 的 
修改 操作 是 由 前 台 进 程 完 成 的 , 但 是 前 台 进 程 只 负责 将 数据 块 从 数据 文件 中 读 到 缓冲 区 中 , 不 负 
责 将 缓冲 区 中 修改 过 的 数据 写 入 数据 文件 。 缓 冲 区 写 和 数据 文件 的 操作 是 由 后 人 台 进 程 DBWR Ж 
完成 的 。DBWR 可 以 根据 系统 的 负载 情况 以 及 数据 块 是 否 被 其 他 进程 使 用 ， 来 将 一 部 分 数据 块 
回 写 到 数据 文件 中 。 在 这 种 机 制 下 ， 某 个 数据 块 被 写 回 文件 的 时 间 可 能 具有 一 定 的 随机 性 ， 有 些 
先 修 改 的 数据 块 可 能 比较 晚 才 被 写 入 数据 文件 。 而 CHECKPOINT 机 制 就 是 对 上 述 机 制 的 一 种 有 
效 补充 。CHECKPOINT 发 生 的 时 候 , CKPT 进程 会 要 求 DBWR 进程 将 某 个 SCN 以 前 的 所 有 被 修 
改 的 块 都 写 回 数据 文件 。 这 样 ， 一 旦 这 次 CHECKPOINT 完成 ， 这 个 SCN 前 的 所 有 数据 变更 都 
已 经 存盘 。 如 果 之 后 发 生 了 实例 故障 ， 在 进行 实例 恢复 时 ， 只 需要 从 这 次 CHECKPOINT 已 经 完 
成 后 的 变化 量 开 始 就 行 了 ，CHECKPOINT 之 前 的 变化 就 不 需要 再 去 考虑 了 。 

到 目前 为 止 ， 我 们 了 解 了 实例 恢复 机 制 的 一 些 基本 原理 ， 就 可 以 大 体 上 理解 REDO 日 志 的 
工作 机 制 了 。 不 过 我 们 还 需要 更 加 深入 一 些 ， 了 解 一 些 内 幕 。 通 过 上 面 的 内 容 ,大 家 也 许 觉 得 对 
实例 恢复 已 经 了 解 得 很 透彻 了 , 但 实际 上 , 还 有 很 多 问题 没有 解决 。 有 些 爱 动 脑筋 的 读者 可 能 要 
问 了 ,如 果 数 据 文件 中 的 变化 已 经 写 盘 ,但 是 REDO 日 志 信息 还 在 日 志 缓 冲 区 中 ,没有 写 人 REDO 
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志 ， 这 种 情况 如 何 恢 复 呢 ? 

这 里 我 们 又 要 引入 一 个 名 词 Write-Ahead-Log， 就 是 日 志 写 和 优先。 日 志 写 人 优先 包含 两 方 
面 的 算法 。 第 一 个 方面 是 ， 在 某 个 缓冲 区 缓存 的 修改 的 变化 矢量 还 没有 写 人 REDO 日 志文 件 之 
前 , 这 个 修改 后 的 缓冲 区 的 数据 不 允许 被 写 人 数据 文件 , 这 样 就 确保 了 在 数据 文件 中 不 可 能 包含 
未 在 REDO 日 志文 件 中 记录 的 变化 。 第 二 个 方面 是 ， 在 对 某 个 数据 的 UNDO 信息 的 变化 矢量 没 
有 被 写 入 REDO 日 志 之 前 ， 这 个 缓冲 区 的 修改 不 能 被 写 人 数据 文件 。 

介质 恢复 和 实例 恢复 的 机 制 是 类 似 的 , 所 不 同 的 是 , 介质 恢复 是 在 存储 的 数据 文件 出 现 故障 
时 进行 的 ， 且 无 法 自动 进行 ， 必 须 手 工 执行 recover database 或 者 recover datafile 命令 来 实施 。 一 
般 来 说 ,介质 恢复 是 以 一 个 恢复 的 数据 文件 为 起 点 进行 恢复 的 , 因此 在 进行 介质 恢复 时 , 需要 使 
用 归档 日 志 。 


5.2.2 ”变化 矢量 和 REDO 记录 


本 节 将 介绍 一 些 REDO 日 志 底 层 的 概念 。 只 有 明白 了 这 些 概念 ， 我 们 才能 更 加 深入 地 了 解 
REDO 日 志 及 其 相关 的 管理 和 优化 要 点 。 首 先 我 们 要 了 解 的 就 是 变化 矢量 ( Change Vector, CV ). 
变化 矢量 是 组 成 REDO 信息 的 基础 ， 一 个 变化 矢量 描述 了 对 一 个 独立 数据 块 进行 的 一 次 独立 修 
改 操作 。 这 里 要 注意 的 是 ，CV 的 定义 里 包含 了 两 层 含义 ， 即 一 个 CV 只 针对 一 个 数据 块 的 变更 ， 

个 CV 只 包含 一 个 变化 ,每 个 CV 都 包含 了 对 文件 的 修改 ,因此 在 每 个 CV 中 都 有 一 个 OPCODE 
出 修改 的 类 型 。 不 同 OPCODE 的 CV， 其 组 成 也 是 不 同 的 ，OPCODE 的 取 值 范围 如 代码 清 
5-1 所 示 。 


代码 清单 5-1 


Layer 1 : Transaction Control - KCOCOTCT 
Opcode 1 : KTZFMT 


Opcode 2 : KTZRDH 
Opcode 3 : KTZARC 
Opcode 4 : KTZREP 


Layer 2 : Transaction Read - KCOCOTRD 


Layer 3 : Transaction Update - KCOCOTUP 


Layer 4 : Transaction Block - KCOCOTBK [ktbcts. h] 
Opcode 1: Block Cleanout 
Opcode 2 : Physical Cleanout 
Opcode 3 : Single Array Change 
Opcode 4 : Multiple Changes to an Array 
Opcode 5 : Format Block 
Layer 5 : Transaction Undo - KCOCOTUN [ktucts. h] 


Opcode 1 : Undo block or undo segment header - KTURDB 
Opcode 2 : Update rollback segment header - KTURDH 
Opcode 3 : Rollout a transaction begin 

Opcode 4 : Commit transaction (transaction table update) 
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Layer 


Layer 


no und 
Opcode 5 : 
Opcode 6 
Opcode 7 
Opcode 8 
Opcode 9 
Opcode 10 : 
Opcode 11 : 
Opcode 12 : 
Opcode 13 : 
Opcode 14 : 
Opcode 15 : 
Opcode 16 : 
Opcode 17 : 
Opcode 18 : 
Opcode 19 : 
Opcode 20 
Opcode 24 
6 : Contro 
10 : INDEX - 
Opcode 1 
Opcode 2 : 
Opcode 3 : 
Opcode 4 
Opcode 5 : 
Opcode 6 
Opcode 7 
Opcode 8 
Opcode 9 
Opcode 10 : 
Opcode 11 : 
Opcode 12 : 
Opcode 13 : 
Opcode 14 : 
Opcode 15 : 
Opcode 16 : 
Opcode 17 : 
Opcode 18 : 
Opcode 19 : 
Opcode 20 
Opcode 21 
Opcode 22 : 
Opcode 23 : 
Opcode 24 
Opcode 25 : 
Opcode 26 
Opcode 27 
Opcode 28 
Opcode 29 
Opcode 30 
Opcode 31 
Opcode 32 


: Apply Itl Redo 


0 record 

Create rollback segment (format) - no undo record 
Rollback record index in an undo block - KTUI RB 
Begin transaction (transaction table update) 

Mark transaction as dead 


: Undo routine to rollback the extend of a rollback segment 


Redo to perform the rollback of extend of rollback segment 
to the segment header 
Rollback DBA in transaction table entry - KTUBRB 

Change transaction state (in transaction table entry) 
Convert rollback segment format (V6 -> V7) 
Change extent allocation parameters in a rollback segment 


Transaction start audit log record 
Transaction continue audit log record 
Kernel Transaction Undo Relog CHanGe - KTURLGU 


File - KCOCODCF [tbs.h] 


KCOCODI X [kdi . h] 

oad index block (Loader with direct mode) 
nsert leaf row 
Purge leaf row 
ark leaf row deleted 

Restore leaf row (clear leaf delete flags) 
Lock index block 
Unlock index block 


nitialize new leaf block 


Set leaf block next link 

Se eaf block previous link 

Init root block after split 

Make leaf block empty 

Restore block before i mage 

Branch block row insert 

Branch block row purge 

Initialize new branch block 

Update keydata in row 

Clear row's split flag 

Set row' s split flag 

General undo above the cache (undo) 
Undo operation on leaf key above the cache (undo) 
Restore block to b-tree 

Shrink ITL (transaction entries) 
Format root block redo 

Undo of format root block (undo) 
Redo for undo of format root block 
Undo for migrating block 

Redo for migrating block 

ГОТ leaf block nonkey update 

Cirect load root redo 

Combine operation for insert and restore rows 
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Layer 


Layer 


Layer 


Layer 


Layer 


Layer 


11 : Row Access - KCOCODRW [kdocts. h] 
Opcode 1 : Interpret Undo Record (Undo) 
Opcode 2 : Insert Row Piece 
Opcode 3 : Drop Row Piece 
Opcode 4 : Lock Row Piece 
Opcode 5 : Update Row Piece 
Opcode 6 : Overwrite Row Piece 
Opcode 7 : Manipulate First Column (add or delete the 1rst 
Opcode 8 : Change Forwarding address 
Opcode 9 : Change the Cluster Key Index 
Opcode 10 : Set Key Links (change the forward & backward key links 
on a cluster key) 
Opcode 11 : Quick Multi-Insert (ex: insert as select 
Opcode 12 : Quick Multi-Delete 
Opcode 13 : Toggle Block Header flags 
12 : Cluster KCOCODCL [?] 
13 : Transaction Segment - KCOCOTSG [ktscts. h] 
Opcode 1 : Data segmen ormat 
Opcode 2 : Merge 
Opcode 3 : Set link in block 
Opcode 4 : Not used 
Opcode 5 : New block (affects segment header 
Opcode 6 : Format block (affects data block) 
Opcode 7 : Record link 
Opcode 8 : Undo free list (undo) 
Opcode 9 : Redo free list head (called as part of undo) 
Opcode 9 : Format free list block (freelist group) 
Opcode 11 : Format new blocks in free list 
Opcode 12 : free list clear 
Opcode 13 : free list restore (back) (undo of opcode 12) 
14 : Transaction Extent KCOCOTEX [kte. h] 
Opcode 1 : Add extent to segment 
Opcode 2 : Unlock Segment Header 
Opcode 3 : Extent DEallocation (DEL) 
Opcode 4 : Undo to Add extent operation (see opcode 1) 
Opcode 5 : Extent Incarnation number increment 
Opcode 6 : Lock segment Header 
Opcode 7 : Undo to rollback extent deallocation (see opcode 3) 
Opcode 8 : Apply Position Update (truncate 
Opcode 9 : Link blocks to Freelist 
Opcode 10 : Unlink blocks from Freelist 
Opcode 11 : Undo to Apply Position Update (see opcode 8) 
Opcode 12 : Convert segment header to 6.2.x type 
15 : Table Space - KCOCOTTS [КЕЕ В] 
Opcode 1 : Format deferred rollback segment header 
Opcode 2 : Add deferred rollback record 
Opcode 3 : Move to next block 
Opcode 4 : Point to next deferred rollback record 
16 : Row Cache - KCOCOQRC 
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column) 
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Layer 17 : Recovery (REDO) KCOCORCV [kcv.h] 
Opcode 1 : End Hot Backup : This operation clears the hot backup 
in-progress flags in the indicated list of files 
Opcode 2 : Enable Thread : This operation creates a redo record 
signalling that a thread has been enabled 
Opcode 3 : Crash Recovery Marker 
Opcode 4 : Resizeable datafiles 
Opcode 5 : Tablespace ONline 
Opcode 6 : Tablespace OFFline 
Opcode 7 : Tablespace ReaD Write 
Opcode 8 : Tablespace ReaD Only 
Opcode 9 : ADDing datafiles to database 
Opcode 10 : Tablespace DRoP 
Opcode 11 Tablespace PitR 
Layer 18 : Hot Backup Log Blocks - KCOCOHLB [kcb. h] 
Opcode 1 : Log block i mage 
Opcode 2 : Recovery testing 
Layer 19 : Direct Loader Log Blocks - KCOCODLB [kcbl.h] 
Opcode 1: Direct block logging 
Opcode 2 : Invalidate range 
Opcode 3 : Direct block reloggi ng 
Opcode 4 : Invalidate range relogging 
Layer 20 : Compatibility Segment operations - KCOCOKCK КСК. h] 
Opcode 1 : Format compatibility segment KCKFCS 
Opcode 2 : Update compatibility segment KCKUCS 
Layer 21 : LOB segment operations - KCOCOLFS [kdl 2. h 
Opcode 1: Write data into ILOB data block - KDLOPWRI 
Layer 22 : Tab espace bitmapped file operations - KCOCOTBF [ktfb.h] 
Opcode 1 : format space header - KTFBHFO 
Opcode 2 : space header generic redo - KTFBHREDO 
Opcode 3 : space header undo - KTFBHUNDO 
Opcode 4 : space bitmap block format KTFBBFO 
Opcode 5 : bitmap block generic redo - KTFBBREDO 
Layer 23 : write behind logging of blocks - KCOCOLWR [kcbb.h] 
Opcode 1 : Dummy block written callback - KCBBLWR 
Layer 24 : Logminer related (DDL or 0BJV£ redo) KCOCOKRV [krv.h] 
Opcode : common portion of the ddl KRVDDL 
Opcode : direct load redo - KRVDLR 
Opcode : lob related info - KRVLOB 
Opcode : misc info - KRVMISC 
Opcode : user info - KRVUSER 
REDO 记录 是 由 一 组 CV 组 成 的 ， 这 组 CV 完成 对 数据 库 的 一 个 原子 修改 操作 。 比 如 ， 一 个 
REDO 记录 里 可 能 包含 3 个 CV， 第 一 个 是 对 UNDO SEGMENT HEADER 的 修改 ， 第 二 个 是 对 
UNDO SEGMENT 的 修改 ， 第 三 个 是 对 DATA BLOCK 的 修改 。 而 一 个 事务 可 能 包含 多 个 REDO 


记录 。 
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当前 台 进 程 要 对 某 个 数据 块 进行 修改 的 时 候 ， 首 先 要 形成 相关 的 CV， 然 后 把 多 个 Cv 组 成 
REDO 记录 ， 再 把 REDO 记录 写 入 日 志 绥 冲 区 后 ， 前 台 进 程 可 以 将 CV 提交 到 相关 的 数据 块 上 。 

下 面 通 过 一 个 示例 来 学 习 REDO 记录 和 变化 矢量 。 我 们 设计 的 场景 是 ， 首 先 在 SCOTT 下 创 
建 一 张 表 一 一 SCOTT.T4: 

create table t4 (a integer); 

然后 查看 当前 的 SCN 信息 : 


SQL» select max(ktuxescnw * power(2, 
MAX( KTUXESCNW* POWER( 2, 32) +KTUXESCNB) 


16230857 
执行 一 条 INSERT 语句， 然后 以 这 条 语句 进行 分 析 : 


insert into t4 values (1); 

commi t ; 

SQL» select max(ktuxescnw * power(2, 
MAX( KTUXESCNW* POWER( 2, 32) +KTUXESCNB) 


16230863 
通过 这 两 个 SCN 值 ， 对 当前 的 REDO 日 志 进 行 转 储 : 


em dump logfile 'd:Voracleloradatalora92|redo01.lo0g' 
63; 


32) * ktuxescnb) from x$ktuxe; 


32) * ktuxescnb) from x$ktuxe; 


SQL» alter sys scn min 16230857 


scn max 162308 
系统 已 更 改 。 


下 面 的 内 容 就 是 INSERT 语句 所 产生 的 ， 第 一 条 ВЕРО 记录 内 容 如 下 : 


REDO RECORD - Тһгеай: 1 RBA: 0x0000a1.000040ce.0010 LEN: 0x0054 VLD: 
SCN: 0x0000.00f7a9c9 SUBSCN: 1 03/12/2008 09:37:49 
CHANGE #1 TYP:0 CLS:33 AFN:2 DBA:0x00800111 SCN:0x0000.00f7a9c7 SEQ: 1 OP:5.4 


可 以 看 出 ,这 个 REDO 记 录 的 RBA 是 0x0000al1.000040ce.0010 ,转换 成 十 进 制 就 是 161.64.16， 
LOG SEQUENCE 号 是 161， 在 REDO 日 志 中 的 块 号 是 64， 起 始 字 节 是 块 内 的 16B。 这 个 REDO 
记录 的 长 度 是 84B ( 0X54 )。 

“VLD:0X01” 表 示 该 REDO 记录 的 类 型 ,“0X01” 表 示 CHANGE VECTOR COPIED IN. 
“CHANGE#1” 表 示 这 是 该 REDO 记录 的 第 一 个 СУ. 根据 上 面 的 OPCODE 清单 可 知 ,， "OP:5.4" 
表示 Commit transaction (transaction table update )， 即 修改 事务 表 。RDBA 是 “2/273”， 通 过 
DBA_EXTENTS 查询 为 _ SYSSMU3$。 

继续 看 下 一 条 REDO 记录 : 


0x01 


REDO RECORD - Thread:1 RBA: 0x0000a1.000040cf.0010 LEN: 0x0058 VLD: 0x02 

SCN: 0x0000.00f7a9cb SUBSCN: 1 03/12/2008 09:37:57 

CHANGE #1 MEDIA RECOVERY MARKER SCN: 0х0000. 00000000 SEQ: 0 ОР: 23. 1 

Block Written - afn: 2 rdba: 0x008095f1(2, 38385) ----undo segment 
scn: 0x0000.00f 79cf 1 seq: 0x02 #19: 0x04 

Block Written - afn: 2 rdba: 0x0080726b(2,29291) 1 = eee undo segment 
scn: 0x0000.00f7alel seq: 0x02 fig:0x04  ------ undo segment 

Block Written - afn: 2 rdba: 0x00806e2e(2,28206) = ee undo segment 
scn: 0x0000.00f79d50 seq: 0x02 #19: 0x04 
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这 个 REDO 记录 的 VLD 是 2， 表 示 这 个 REDO 记录 里 分 配 并 存储 了 一 个 SCN。 来 看 第 一 个 
CHANGE: 

OP:23.1, E} OPCODE 为 23.1, 表示 产生 一 些 WRITE BEHIND LOGGING 信息 (Dummy block 
written callback - KCBBLWR )。 下 一 条 REDO 记录 开始 是 针对 TA 表 的 操作 。 


REDO RECORD - Thread:1 RBA: 0x0000a1.000040d0.0010 LEN: 0x00b8 VLD: 0x01 
SCN: 0x0000.00f7a9cd SUBSCN: 1 03/12/2008 09:38:03 
CHANGE #1 TYP:0 CLS: 4 AFN:5 DBA:0x01401a63 SCN: 0x0000.00f7a965 SEQ: 3 ОР: 13. 28 
Redo on Level 1 Bitmap Block --- 针 对 15T ВМВ 的 操作 
Redo to add range 
bdba: Length: 16 
CHANGE #2 TYP:0 CLS: 8 AFN:5 DBA:0x01401a61 SCN: 0х0000. 00+ 7а965 SEQ: 2 0P:13.22 
----dba (5/6753) -- scott.t4 &gsegment header ,设置 高 水 位 
Redo on Levell Bitmap Block 
Redo to set hwm 
Opcode: 32 Highwater:: 0x01401a71 ext# 0 bl k#: 16 ext size: 16 
#blocks in seg. hdr's freelists: 0 
#blocks below: 13 
mapblk 0x00000000 offset: 0 


这 个 ВЕРО 记录 是 对 SCOTT.TA 表 头 的 操作 。 下 面 的 几 个 REDO 记录 都 是 格式 化 数据 块 ， 
为 了 简化 起 见 ， 只 列 出 其 中 的 一 个 : 


REDO RECORD - Thread:1 RBA: 0x0000a1.000040d0.00c8 LEN: 0х003с VLD: 0x01 

SCN: 0x0000.00f7a9cd SUBSCN: 1 03/12/2008 09:38:03 

CHANGE #1 TYP:1 CLS: 1 AFN:5 DBA:0x01401a64 SCN:0x0000.00f7a9cd SEQ: 1 ОР: 13. 21 
--dba(5/6756) --scott.t4, 格式 化 BLOCK 

ktspbfredo - Format Pagetable Datablock 

Рагепі (11) DBA: typ: 1 objd: 32027 itls: 2 fmt flag: 0 poff: 0 


中 间 省 略 了 几 个 REDO 记录 ， 直 接 来 看 包含 INSERT 话 句 的 REDO 记录 : 


REDO RECORD - Thread:1 RBA: 0x0000a1.000040d2.00b0 LEN: 0х015с VLD: 0x01 

SCN: 0x0000.00f7a9cd SUBSCN: 1 03/12/2008 09:38:03 

CHANGE #1 TYP:0 CLS:23 AFN: 2 DBA:0x00800071 SCN:0x0000.00f7a38b SEQ: 1 OP:5.2 

----Update rollback segment header - KTURDH SYS SYSSMU2$ 

ktudh redo: slt: 0x000f sqn: 0x00004947 flg: 0x0012 siz: 80 fbi: 0 

ba: 0x008090cb. 0550. 13 pxid: 0х0000. 000. 00000000 

CHANGE #2 TYP: 0 CLS:24 AFN: 2 DBA: 0x008090cb SCN: 0x0000.00f7a38a SEQ: 3 0P:5.1 

---Undo block or undo segment header - KTURDB SYS_SYSSMU4$ 

ktudb redo: siz: 80 spc: 2746 flg: 0x0012 seq: 0x0550 rec: 0x13 

xid: 0x0004. 00f. 00004947 

ktubl redo: slt: 15 rci: 0 opc: 11.1 objn: 32027 objd: 32027 tsn: 5 

----|nterpret Undo Record (Undo) , £rxrscott.t4 ÆR UNDO 数据 

Undo type: Regular undo Begin trans Last buffer split: No 

Temp Object: No 

Tablespace Undo: No 
0x00000000 prev c uba: 0x008090cb.0550.10 

prev ctl max cmt scn: 0x0000.00f78d7e prev tx cmt scn: 0x0000. 00f 78f06 

KDO undo record 

KTB Redo 

0p: 0x03 ver: 0x01 

0p: Z 

tI Undo of first (ever) change to the ITL, KAI ITL 的 修改 


= 
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天 


DO Op code: DRP row dependencies Disabled 

- Delete Row Piece 

xtype: XA bdba: 0х01401а65 hdba: 0x01401a63 
- ROWI D 

itli: 1 ispac: 0 maxfr: 2401 

abn: 0 slot: 0(0x0) 


~ 


-Insert Row Piece , л — 12, 
KTB Redo 
op: 0x01 ver: 0x01 


---First change to ITL by this TX. Copy redo to ITL 
KDO Op code: IRP row dependencies Disabled 

--Single Insert Row Piece， 行 插入 操作 

xtype: XA bdba: 0x01401a65 hdba: 0х01401а63 

- -- 对 应 的 表 是 scott.t4 
itli: 1 ispac: 0 maxfr: 2401 
tabn: 0 slot: 0(0x0) size/delt: 6 
fb: --H-FL-- Ib: 0х1 cc: 1 


col 0: [ 2] c102 
- 十 进 制 ] ， 就 是 我 们 插入 的 数据 


CHANGE #3 TYP:0 CLS: 1 AFN:5 DBA:0x01401a65 SCN:0x0000.00f7a9cd SEQ: 2 OP:11.2 


op: F xid: 0х0004. 00+. 00004947 uba: 0х008090ср. 0550. 13 


CHANGE #4 MEDIA RECOVERY MARKER SCN: 0х0000. 00000000 SEQ: 0 0р: 5. 20 


---Transaction continue audit log record, 记录 SESSI0 
session number 11 
serial number 115 
transaction name 


N 信息 


这 个 事务 的 最 后 一 条 REDO 记录 就 是 COMMIT 产生 的 记录 : 
REDO RECORD - Thread:1 RBA: 0x0000a1.000040d4.0010 LEN: 0x0054 VLD: 0x01 


SCN: 0x0000.00f7a9cf SUBSCN: 1 03/12/2008 09:38:03 


CHANGE £1 TYP:0 CLS:23 AFN:2 DBA:0x00800071 SCN:0x0000.00f7a9cd SEQ: 1 OP:5.4 


--Commit transaction (transaction table update) 


ktucm redo: slt: 0x000f sqn: 0x00004947 srt: 0 sta: 9 flg: 0x2 


ktucf redo: uba: 0x008090cb. 0550.13 ext: 2 spc: 2664 


5.23 “日 志 缓冲 和 LGWR 


fbi: 0 


REDO 日 志 的 产生 十 分 频繁 ,几乎 每 秒 都 有 几 十 万 字 节 到 几 兆 字 节 的 REDO 日 志 产 生 , Ж 
些 大 型 数据 库 每 秒 产生 的 REDO 日 志 量 甚至 达到 了 10MB 以 上 ( 老 白 曾 见 过 一 个 每 秒 产生 近 


200MB REDO 日 志 的 系统 ,不 过 这 是 压力 测试 环境 下 的 数据 )。 


不 过 前 台 进 程 每 次 产生 的 REDO 


量 并 不 大 , 一 般 在 几 百 字 节 到 几 千 字 节 , 而 一 般 来 说 , 一 个 事务 所 产生 的 REDO 量 也 大 致 如 此 。 


基于 REDO 的 这 个 特点 ， 如 果 每 次 REDO 产生 后 都 必须 写 人 


两 个 问题 。 第 一 个 是 REDO 日 志文 件 写 入 的 频率 过 高 ,会 导致 其 МО 性 能 出 现 问题 。 第 二 个 是 


REDO 日 志文 件 ， 那 么 就 会 存在 


如 果 由 前 台 进 程 来 完成 REDO 日 志 的 写 和 信 ， 那 么 会 时 臻 大量 并 发 的 前 台 进 程 产生 R REDO 日 志 


关中 引入 了 LGWR 后 台 进 程 和 日 


为 了 解决 这 两 个 问题 ，Oracle 在 REDO НАЯ 
Же. 
日 志 缓冲 用 来 缓存 前 台 进 程 产生 的 REDO 日 志 信 ЕЙ 息 。 前 ri 


台 进 程 可 以 将 产生 的 REDO 日 志 信 


息 写 和 日 志 缓冲 ， 而 不 需要 直接 写 和 人 REDO 日 志文 件 ， 这 样 就 大 大 提高 了 REDO 日 志 产生 和 保 
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存 的 时 间 ， 从 而 提高 数据 库 在 高 并 发 情况 下 的 性 能 。 

既然 前 台 进 程 不 将 REDO 日 志 信 息 写 人 REDO 日 志文 件 了 ， 那 么 就 必须 要 有 一 个 后 台 进 程 
来 完成 这 个 工作 。 这 个 后 台 进 程 就 是 LGWR, LGWR 进程 的 主要 工作 就 是 将 日 志 缓 冲 中 的 数据 
批量 写 人 到 REDO 日 志文 件 中 。 在 Oracle 数据 库 中 ， 只 要 数据 库 的 改变 被 写 人 到 REDO 日 志文 
件 中 ， 那 么 就 可 以 确保 相关 的 事务 不 会 丢失 了 。 

引入 日 志 组 冲 提高 了 整个 数据 库 RDBMS 写 日 志 的 性 能 , 但 是 如 何 确 保 一 个 已 经 提交 的 事务 
确实 被 保存 在 数据 库 中 , 不 会 因为 之 后 数据 库 发 生 故 障 而 丢失 呢 ? 实际 上 , 在 前 面 两 节 中 介绍 的 
REDO 日 志 的 一 些 基 本 算法 就 可 以 确保 这 一 点 。 首 先 ，Write-Ahead-Log 协议 确保 了 只 要 保存 到 
REDO 日 志文 件 中 的 数据 库 变 化 一 定 能 够 被 重演 ,不 会 丢失 ， 也 不 会 产生 二 义 性 。 其 次 ,在 事务 
提交 的 时 候 ， 会 产生 一 个 提交 CY， 这 个 CV 被 写 入 日 志 缓 冲 后 ， 前 人 台 进 程 会 发 出 一 个 信号 ， 要 
+K LGWR 将 和 这 个 事务 相关 的 REDO 日 志 信 息 写 入 到 REDO 日 志文 件 中 。 只 有 这 个 事务 相关 的 
REDO 日 志 信息 确实 被 写 人 REDO 日 志文 件 时 ， 前 台 进 程 才 会 向 客户 端 发 出 事务 提交 成 功 的 消 
息 ,这 样 一 个 事务 才 算 是 被 提交 完成 了 。 在 这 个 协议 下 ， 只 要 客户 端 收 到 了 提交 完成 的 消息 , 那 
么 就 可 以 确保 该 事务 已 经 存盘 ， 不 会 丢失 。LGWR 会 绕 过 操作 系统 的 缓冲 ， 直 接 写 入 数据 文件 ， 
以 确保 REDO 日 志 的 信息 不 会 因为 操作 系统 出 现 故障 ( 比如 宕 机 ) 而 丢失 应 写 和 人 REDO 日 志文 
件 的 数据 。 

实际 上 ， 虽 然 Oracle 数据 库 使 用 了 绕 过 缓冲 直接 写 REDO 日 志文 件 的 方法 ， 以 避免 操作 系 
统 故 障 导致 的 数据 丢失 ， 但 我 们 还 是 无 法 确保 这 些 数据 已 经 被 写 到 了 物理 磁盘 上 。 因 为 RDBMS 
使 用 的 绝 大 多 数 存储 系统 都 是 带 有 写 缓 冲 的 , 写 缓冲 可 以 有 效 地 提高 存储 系统 写 性 能 , 不 过 也 带 
来 了 另外 的 一 个 问题 ， 就 是 一 旦 存储 出 现 故障 ， 可 能 会 导致 REDO 日 志 的 信息 丢失 ， 甚 至 导致 
REDO 日 志 严 重 损坏 。 尽 管 存 储 故 障 出 现 的 概率 较 小 , 但 是 这 种 小 概率 事件 一 旦 发 生 ， 还 是 会 
致 一 些 数据 库 事务 的 丢失 。 因 此 , 虽然 Oracle 的 内 部 算法 可 以 确保 一 旦 事务 提交 成 功 , 就 被 保存 
完毕 , 但 是 提交 成 功 的 事务 还 是 可 能 丢失 。 

实际 上 ，Oracle 在 设计 REDO 日 志文 件 的 时 候 , 已 经 最 大 限度 地 考虑 了 其 安全 性 , REDO 日 
志文 件 的 块 大 小 和 数据 库 完全 不 同 ,但 和 操作 系统 的 IO 块 大 小 完全 相同 。 这 种 设计 确保 了 一 个 
REDO 日 志 块 在 一 次 物理 VO 中 被 同时 写 人 ， 因 此 REDO 日 志 块 不 会 出 现 块 断裂 的 现象 。 

了 解 日 志 缓 冲 和 LGWR 的 算法 ， 有 助 于 我 们 分 析 和 解决 相关 的 性 能 问题 。 用 一 句 话 来 概 
括 一 一 日 志 缓 冲 是 一 个 循环 使 用 的 顺序 型 缓存 。 这 里 包含 了 两 层 含义 。 首先, 日 志 缓 冲 是 顺序 读 
写 的 缓冲 ; 其 次 ， 日 志 缓 冲 是 循环 缓冲 ， 当 日 志 缓 冲 写 满 后 ， 会 回 到 头 部 来 继续 写 人 REDO H 
志 信 息 。 日 志 绥 冲 数据 的 写 人 是 由 前 台 进 程 来 完成 的 ， 并 且 是 并 发 的 ， 每 个 前 台 进 程 在 生成 了 
REDO 日 志 信息 后 , 需要 首先 在 日 志 缓 冲 中 分 配 空间 , 然后 将 REDO 日 志 信息 写 入 到 日 志 缓 冲 中 
去 。 在 日 志 缓 冲 中 分 配 空间 是 一 种 串 行 的 操作 , 因此 Oracle 在 设计 这 方面 的 算法 时 , 把 日 志 缓 冲 
空间 分 配 和 复制 REDO 日 志 数 据 到 日 志 缓 冲 这 两 种 操作 分 离 了 。 一 旦 分 配 了 日 志 缓 冲 空间 ， 就 
可 以 释放 相关 的 门 ， 这 样 ， 其 他 前 台 进 程 就 可 以 继续 分 配 空 间 了 。( 这 里 所 说 的 前 台 进 程 是 一 种 
泛 指 ， 只 是 为 了 表述 方便 而 已 ， 读 者 一 定 要 注意 ， 因 为 后 台 进 程 也 会 对 数据 库 进 行 修改 ， 也 需要 
产生 REDO 日 志 信 息 ， 后 台 进 程 的 REDO 操作 和 前 台 进 程 是 大 体 一 致 的 。) 
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前 台 进 程 写 入 REDO 信息 会 使 日 志 缓 冲 的 尾部 指针 不 停 地 向 前 推进 ， 而 LGWR 这 个 后 台 进 
程 会 不 停 地 从 日 志 组 冲 的 头 部 指针 开始 查找 还 未 写 和 人 REDO 日 志文 件 的 日 志 缓 冲 信 息 ， 然 后 将 
这 些 信息 写 和 人 REDO 日 志文 件 中 ， 并 将 缓冲 头 部 指针 不 停 地 向 后 推进 。 若 日 志 缓 冲 的 头 部 指针 
和 尾部 指针 重合 ， 就 说 明 当 前 的 日 志 缓 冲 是 空 的 。 而 如 果 前 台 进 程 在 日 志 缓 冲 中 分 配 空间 , 会 使 
日 志 缓冲 的 尾部 指针 一 直 向 前 推进 。 一 有 旦 日 志 缓 冲 的 尾部 指针 追 上 了 头 部 指针 , 日志 缓 冲 就 无 法 
再 分 配 新 的 空间 给 后 台 进 程 ， 后 台 进 程 必须 要 等 候 LGWR 将 这 些 数据 写 人 REDO 日 志文 件 ， 然 
后 向 前 推进 头 部 指针 ， 才 可 能 再 次 获得 新 的 可 用 缓冲 空间 。 这 时 ， 前 台 进 程 会 等 待 LOG FILE 
SYNC 事件 。 

为 了 让 LGWR 尽快 将 日 志 缓 冲 中 的 数据 写 入 REDO 日 志文 件 , 以 便于 腾 出 更 多 的 空闲 空间 ， 
Oracle 数据 库 设 计 了 LGWR 写 的 触发 条 件 。 

口 事务 提交 时 。 

а 日 志 缓 冲 中 的 数据 超过 1MB 时 。 

a 当日 志 缓 冲 中 的 数据 超过 了 _log_io_size 隐 含 参数 指定 的 大 小 时 。 
a 每 隔 3 秒 。 

前 面 多 次 提 到 过 ， 当 事务 提交 时 ， 会 产生 一 个 提交 的 REDO 记录 。 这 个 记录 写 人 日 志 缓冲 
后 , 前 台 进 程 会 触发 LGWR 写 操作 。 这 时 前 台 进 程 就 会 等 待 LOG FILE SYNC 事件 , 直到 LGWR 
将 相关 的 数据 写 入 REDO 日 志文 件 ， 等 待 才 会 结束 ， 前 台 进 程 就 会 收 到 提交 成 功 的 消息 。 如 果 
系统 每 秒 的 事务 数量 较 大 ， 比 如 几 十 个 或 者 几 百 个 , KE OLTP 系统 甚至 会 达到 数 千 个 , 在 这 种 
系统 中 ，LGWR 由 于 事务 提交 而 被 激发 的 频率 很 高 ， 日 志 缓 冲 的 信息 会 被 很 快 地 写 人 REDO Н 
志文 件 。 

而 对 于 某 些 系统 来 说 ， 如 果 每 个 事务 的 平均 大 小 很 大 ， 生 成 的 REDO 日 志平 均 数据 量 也 很 
大 ， 比 如 1MB 甚至 更 高 ， 每 秒 的 平均 事务 数 却 很 少 ， 比 如 一 两 个 甚至 不 到 一 个 ， 那 么 这 种 系统 
中 LGWR 由 于 事务 提交 而 被 激发 的 频率 很 低 。 这 样 ， 就 可 能 导致 REDO 日 志 信息 在 日 志 缓冲 中 
被 大 量 积压 , 日 志 缓 冲 中 数据 超过 IMB 的 LGWR 激发 条 件 就 是 为 了 解决 这 种 情况 而 设计 的 。 当 
日 志 缓冲 中 的 积压 数据 很 多 时 , 即便 没有 事务 提交 , 也 会 触发 LGWR 将 缓冲 中 的 数据 写 人 REDO 
日 志文 件 。 

除 此 之 外 ，Oracle 还 通过 log io size 这 个 隐 含 参数 来 进一步 控制 LGWR SERVE, “4 ARR 
冲 中 的 数据 超过 了 该 参数 规定 的 大 小 时 , LGWR 就 会 被 激发 。 这 个 参数 的 默认 值 是 日 志 缓 冲 容量 
的 113， 单 位 是 REDO LOG Block， 可 以 控制 当日 志 缓 冲 中 有 多 少 个 数据 块 被 占用 时 ， 就 要 触发 
LGWR 写 操作 ， 从 而 避免 日 志 缓 冲 被 用 尽 。 

如 果 一 个 空闲 的 系统 很 长 时 间 都 没有 事务 提交 , 日 志 缓 冲 的 使 用 也 很 少 , 就 可 能 导致 日 志 组 
冲 中 的 数据 长 期 没有 被 写 人 REDO 日 志文 件 ， 带 来 丢失 数据 的 风险 。 因 此 Oracle 还 设计 了 一 个 
激发 LGWR 写 操作 的 条 件 ， 设 置 一 个 时 间 触 发 器 ， 每 隔 3 秒 这 个 触发 器 都 会 被 激活 。 被 激活 时 ， 
如 果 发 现 日 志 缓冲 不 为 空 ， 并 且 LGWR 未 处 于 活跃 状态 ， 就 会 产生 一 个 事件 ， 激 活 LGWR。 

前 面 我 们 讨论 了 LGWR 和 日 志 缓 冲 的 一 些 基本 算法 ， 下 面 来 介绍 LOG FILE SYNC 等 待 事 
件 。 该 事件 的 作用 是 等 待 LGWR 将 日 志 缓 冲 的 数据 写 人 REDO 日 志文 件 。 一 般 情 况 下 ， 某 个 事 
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务 在 做 提交 时 ， 会 等 待 LOG FILE SYNC 事件 ， 而 没有 做 提交 操作 的 会 话 则 不 需要 等 待 ， 因 为 前 
台 进 程 只 需要 将 REDO 日 志 信 息 写 人 日 志 缓冲 就 可 以 了 ， 不 需要 等 待 这 些 数据 被 写 人 REDO H 
志文 件 。 不 过 前 台 进 程 在 分 配 日 志 缓冲 时 ， 如 果 发 现 日 志 缓冲 的 尾部 指针 已 经 锯 上 了 头 部 指针 ， 
那么 前 台 进 程 就 要 等 待 LGWR 进程 将 头 部 的 数据 写 入 REDO 日 志文 件 , 然后 释放 日 志 绥 冲 空间 。 
这 时 ， 没 有 做 提交 操作 的 前 台 进 程 都 会 等 待 LOG FILE SYNC 事件 。 这 种 情况 下 ， 加 大 日 志 缓 冲 
就 可 以 减少 大 部 分 的 LOG FILE SYNC 等 待 。 

增加 日 志 缓 冲 的 大 小 , 可 能 会 带 来 另外 一 个 问题 , 比如 , 日 志 缓 冲 从 1MB 增加 到 30MB ( 关 
于 日 志 缓 冲 是 否 需 要 大 于 3MB 的 问题 ， 以 前 我 们 已 经 多 次 讨论 ， 这 里 不 再 著述 ， 大 家 只 需要 记 
住 一 点 就 可 以 了 ， 日 志 缓 冲 大 于 3MB 是 浪费 空间 、 对 性 能 影响 不 大 的 观点 是 错误 的 )， 那 么 
_log_io_size 会 自动 从 300KB 增加 到 10MB ,在 一 个 平均 每 秒 事务 数 较 少 , 并 且 每 个 事务 的 REDO 
尺寸 较 大 的 系统 中 ， 触 发 LGWR 写 操作 的 日 志 缓 冲 数据 量 会 达到 1MB 。 一 般 来 说 ， 在 一 个 大 型 
的 OLTP 系统 里 ,每 次 LGWR 写 人 REDO 日 志文 件 的 大 小 在 几 千 字 节 到 几 万 字 节 之 间 ,LOG FILE 
SYNC 事件 的 平均 等 待 时 间 在 1 ~ 10ms。 如 果 平 均 每 次 写 人 的 数据 量 过 大 ， 会 导致 LOG FILE 
SYNC 的 等 待 时 间 变 长 。 因 此 在 这 种 情况 下 ， 可 能 就 需要 设置 log io size 参数 ， 确 保 LOG FILE 
SYNC 等 待 不 会 过 长 。 

WREKSA REDO 日 志文 件 的 数据 量 不 大 , Mi LOG FILE SYNC 等 待 时 间 却 很 长 ， 比 如 超 
过 100ms, 那么 就 要 分 析 一 下 REDO 日 志文 件 的 IO HERE T o 如 果 REDO 日 志文 件 IO 性 能 不 佳 ， 
或 者 该 文件 所 在 的 IO 热点 较 大 ， 都 可 能 导致 LOG FILE SYNC 等 待 时 间 偏 大 ， 这 种 情况 下 ， 我 
们 可 以 查看 后 台 进 程 的 LOG FILE PARALLEL WRITE 等 待 事 件 。 这 个 事件 一 般 的 等 待 时 间 为 几 
毫秒 ， 如 果 该 事件 的 平均 等 待 时 间 较 长 ， 那 么 就 说 明 REDO 日 志文 件 的 UO 性 能 不 佳 ， 需 要 将 
REDO 日 志文 件 放 到 IO 量 较 小 、 性 能 较 快 的 磁盘 上 。 

在 ОТР 系统 中 , REDO 日 志文 件 的 写 操作 主要 是 小 型 的 ,比较 频繁 , 一 般 大 小 为 几 千 字 节 ， 
而 每 秒 钟 产生 的 写 IO 次 数 会 达到 几 十 、 数 百 甚 至 上 千 。 因 此 REDO 日 志文 件 适 合 存放 于 IOPS 
较 高 、 转 速 较 快 的 磁盘 上 ， 而 IOPS 仅 能 达到 数 百 次 的 SATA 盘 不 适合 存放 REDO 日 志文 件 。 男 
yh, REDO 日 志文 件 的 写 入 是 串 行 的 , 因此 对 其 所 做 的 底层 条 带 化 处 理 , 对 于 REDO 日 志 写 性 能 
的 提升 是 十 分 有 限 的 。 


5.2.4 “日 志 切 换 和 REDO 日 志文 件 


当前 台 进 程 在 日 志 缓 冲 区 中 分 配 空间 的 时 候 ， 实 际 上 已 经 在 REDO 日 志文 件 中 预先 分 配 了 
空间 。 如 果 REDO 日 志文 件 已 经 写 满 ， 无 法 再 分 配 空 间 给 前 台 进 程 ， 就 需要 做 一 次 日 志 切 换 。 
这 时 前 台 进 程 会 向 LGWR 发 出 一 个 日 志 切 换 的 请 求 ， 然 后 等 待 LOG FILE SWITCH 
COMPLETION 事件 。 

日 志 切 换 请 求 发 出 后 ，CKPT 进程 会 进行 一 次 日 志 切换 CHECKPOINT， 而 LGWR 开始 进行 
日 志 切 换 工 作 。 首 先 LGWR 进程 会 通过 控制 文件 中 的 双向 链表 ， 查 找 一 个 可 用 的 REDO 日 志文 
件 ， 将 其 作为 新 的 当前 REDO 日 志 。 此 查找 算法 要 求 该 日 志 是 非 活 动 的 ， 并 且 已 经 完成 了 归档 
(如 果 是 归档 模式 )。Oracle 会 优先 使 用 空闲 状态 的 REDO 日 志 组 作为 当前 REDO 日 志 。 
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在 做 日 志 切 换 时 ， 首 先 要 将 日 志 缓 冲 中 还 没有 写 人 REDO 日 志文 件 的 REDO 记录 写 人 当前 
REDO 日 志文 件 , 然后 将 最 后 一 个 REDO 记录 的 SCN 作为 该 日 志文 件 的 High SCN 记录 在 REDO 
日 志文 件 关 中。 这 些 操作 完成 后 ， 就 可 以 关闭 当前 日 志 了 。 

完成 了 上 一 步骤 后 ， 就 需要 进行 第 二 次 控制 文件 事务 ， 将 刚刚 关闭 的 REDO 日 志 标 识 ; 
active， 将 新 的 当前 REDOLOG 标识 为 current。 如 果 数 据 库 处 于 归档 模式 ， 还 要 将 旧 日 志 组 记录 
到 控制 文件 归档 列表 记录 中 (在 V$ARCHIVE 视图 中 可 看 到 )， 并 且 通 知 归 档 进程 对 该 日 志文 件 
进行 归档 。 在 所 有 的 归档 进程 都 处 于 忙碌 状态 ， 并 且 归 档 进程 总 数 没 有 超过 log archive max | 
processes 的 情况 下 ，LGWR 还 会 生成 一 个 新 归档 进程 来 对 旧 日 志文 件 进行 归档 。 

这 些 操作 都 完成 后 ，LGWR 会 打开 新 日 志 组 的 所 有 成 员 ， 并 在 文件 头 中 记录 下 初始 化 信息 。 
接 下 来 ，LGWR 将 修改 SGA 中 的 标志 位 ， 人 允许 生成 新 的 REDO 日 志 信 息 。 

旧 日 志 组 目前 仍 被 标志 为 active， 当 DBWR 完成 了 CHECKPOINT 所 要 求 的 批量 写 操作 后 ， 
该 日 志 组 的 状态 会 被 标识 为 inactive。 

从 上 述 日 志 切 换 的 步骤 可 以 看 出 , 日志 切换 包含 了 很 多 工作 , 而且 在 整个 过 程 中 , 日 志 的 生 
成 都 是 被 完全 禁止 的 ， 因 此 在 这 期 间 ， 对 数据 库 的 修改 操作 会 被 全 部 阻塞 。 因 此 我 们 常 说 :“ 日 
志 切 换 是 一 种 较为 昂贵 的 操作 。 既然 日 志 切 换 十 分 昂贵 ， 对 系统 性 能 的 影响 较 大 ， 那 么 就 应 该 
想 办 法 减少 日 志 切 换 的 数量 ， 提 高 日 志 切 换 的 速度 。 

减少 日 志 切 换 的 数量 可 以 从 两 个 方面 人 手 , 一 方面 是 减少 日 志 的 产生 量 , 另 一 方面 是 加 大 日 
志文 件 的 大 小 。 

对 于 减少 日 志 产 生 量 ,常规 的 办 法 不 外 乎 使 用 nologging 操作, 如 BULK 操作 direct path write 
操作 等 。 不 过 大 家 要 注意 ， 在 归档 模式 和 非 归 档 模式 下 ， 这 些 nologging 操作 的 效果 是 不 同 的 。 
Julian Dyke 对 常见 的 可 以 使 用 nologging 模式 的 操作 进行 过 测试 , 他 在 一 个 归档 模式 的 数据 库 中 ， 
对 一 张 10 万 条 记录 的 表 进 行 了 一 系列 的 操作 ， 测 试 结果 如 表 5-1 所 示 。 


表 5-1 
Operation LOGGING NOLOGGING 
CREATE TABLE AS SELECT 14238844 39548 
ALTER TABLE MOVE 14227236 45340 
INSERT /*+ APPEND */ 14221904 42452 
CREATE MATERIALIZED VIEW 20726784 3784532 
CREATE INDEX 2042532 24548 
ALTER INDEX REBUILD 2056440 32192 
ALTER INDEX REBUILD ONLINE 2083832 67840 
SQL*Loader(Direct) 14248116 56712 
Online Reorganization 21330788 7169472 


可 以 看 出 , nologging 操作 的 效果 还 是 十 分 明显 的 。CTAS 操作 的 REDO 日 志 量 从 14MB 下 降 
到 39KB 左右 。 老 白 曾 经 也 做 过 一 个 类 似 的 测试 ,测试 环境 是 在 一 个 非 归档 模式 的 数据 库 中 , ЭШ 
过 DBA_OBJECTS 生成 了 一 张 具 有 10 万 条 记录 的 表 。 做 CTAS 操作 时 ， 在 没有 使 用 nologging 
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的 情况 下 ,产生 的 REDO 量 是 113352B ,在 使 用 nologging 的 情况 下 ,产生 的 REDO 量 是 176840B 。 
从 数据 上 看 ，nologgging 并 没有 减少 ВЕРО 产生 量 , 在 非 归档 模式 下 ,， 像 CTAS 这 样 的 操作 本 身 
产生 的 REDO 量 就 很 有 限 ， 因 此 nologging 的 作用 就 不 大 了 。 

另外 ,在 归档 模式 下 , direct path write 操作 的 REDO 量 大 幅 减少 了 , 这 是 什么 原因 导致 的 呢 ? 
我 们 通过 转 储 REDO 日 志 来 看 一 看 INSERT /*- APPEND */ 操 作 产 生 的 REDO 和 普通 的 INSERT 
SELECT 操作 产生 的 REDO 有 什么 不 同 。 


REDO RECORD - Thread:1 RBA: 0x0006d1.0000003f.0130 LEN: 0x2050 VLD: 0x01 
SCN: 0x0000.053653c2 SUBSCN: 2 09/21/2010 09:56:40 
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 ОР: 24.6 
CHANGE #2 TYP:1 CLS: 1 AFN:10 DBA:0x0280c406 0BJ:122858 SCN:0x0000.053653bd SEQ: 1 
0P:19.1 
Direct Loader block redo entry 
Block header dump: 0x00000000 
Object id on Block? Y 
seg/obj: Oxldfea csc: 0x00.53653bc itc: 3 flg: E typ: 1 - DATA 
brn: 0 bdba: 0x280c38a ver: 0x01 opc: 0 
inc: 0 exflg: 0 


Itl Xi d Uba Flag Lek Scn| Fsc 
0x01 0x0001.00a.000054d6 0x00000000.0000.00 ---- 0 fsc 0x0000. 00000000 
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0х0000. 00000000 
0x03 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000. 00000000 


data block dump,data header at 0xb68ab288 


tsiz: 0х1#80 
hsiz: Oxc8 

pbl: 0xb68ab288 
bdba: 0x00000000 


16543210 
flags-------- 
ntab=1 
nrow=91 
frre= 
fsbo=0xc8 
fseoz0x432 
avsp=0x36a 
tosp=0x36a 
Охе: pti[0] nrow=91 offs=0 
0x12: pri[0 of fs=0x1f 36 
0x14: pri[l offs=0xleea 
0x16: pri[2 offs=0xleal 
0x18: pri [3 of fs=0xle57 
0xla:pri[4 offsz0üx1e09 
0х1с:ргі[5 of fs=0xldbe 
Oxle: pri [6 of fs=0x1d69 
0x20: pri[7 of fs=0xldle 
0x22: pri[8 of fs=0xlcd2 
0x24: pri [9 of fs=0x1c79 
0x26:pri [10] of fs=0x1c2f 
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可 以 看 到 ， 在 归档 模式 下 ，direct path load 操作 将 整个 数据 块 放 入 REDO 日 志 中 ， 这 样 既 大 
幅 减 少 了 КЕРО 的 产生 量 ， 叉 保证 了 不 会 丢失 数据 。 在 非 归档 模式 下 ，direct path load 操作 产生 
的 日 志 为 : 


REDO RECORD - Thread:1 RBA: 0x0006d0.0000bf37.00fc LEN: 0x0060 VLD: 0x01 

SCN: 0x0000.05364c72 SUBSCN: 2 09/21/2010 09:45:57 

CHANGE £1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 0р: 24. 6 

CHANGE #2 | NVLD АЕМ: 10 DBA: 0x0280c386 BLKS:0x0003 SCN:0x0000.05364c72 SEQ: 1 ОР: 19. 2 
Direct Loader invalidate block range redo entry 


在 这 种 情况 下 ， 如 果 数 据 库 产 生 故 障 ， 这 个 数据 块 就 无 法 恢复 了 ， 可 能 成 为 坏 块 。 

除了 减少 REDO 日 志 产 生 量 以 外 , 减少 日 志 切 换 还 可 以 从 加 大 REDO 日 志文 件 的 大 小 人 手 。 
比如 ， 一 个 每 秒 产生 IMB 数据 的 系统 ， 每 分 钟 产生 的 数据 是 60MB ， 如 果 REDO 日 志文 件 的 大 
小 是 120MB, JZ JJ 2 分 钟 就 会 产生 一 次 日 志 切 换 。 而 如 果 我 们 把 REDO 日 志文 件 的 大 小 增 
加 到 600MB ， 那 么 平均 10 分 钟 才 会 产生 一 次 日 志 切 换 。 

有 些 DBA 担心 加 大 REDO 日 志文 件 后 会 增加 数据 丢失 的 风险 。 的 确 , REDO 日 志文 件 越 大 ， 
其 所 包含 的 REDO 记录 的 数量 就 越 多 。 一 旦 整个 REDO 日 志文 件 丢 失 或 者 损坏 ， 可 能 丢失 的 数 
据 量 就 会 增加 。 实 际 上 ， 整 个 REDO 日 志 丢 失 的 可 能 性 极 小 ， 最 可 能 发 生 的 是 REDO 日 志文 件 
被 误 删 。 而 如 果 存 储 出 现 故障 ,导致 REDO 日 志文 件 损坏 , 那么 受 影响 的 肯定 将 是 所 有 的 REDO 
日 志文 件 ， 而 不 是 某 一 个 文件 。 此 时 无 论 REDO 日 志 信息 是 存储 在 一 个 REDO 日 志文 件 中 ,还 
是 存储 在 两 个 REDO 日 志文 件 中 ， 其 结果 都 是 完全 一 样 的 。 

还 有 一 种 最 常见 的 情况 ， 就 是 服务 器 突然 宕 机 ， 这 时 REDO 日 志文 件 的 大 小 不 同 可 能 造成 
的 数据 丢失 是 和 否 也 会 不 同 呢 ? 首先 我 们 要 了 解 一 下 服务 器 罕 机 时 可 能 丢失 的 数据 有 哪些 。 如 果 是 
已 经 提交 的 数据 ，CHECKPOINT 已 经 推进 到 的 部 分 ， 就 已 经 被 写 人 数据 文件 了 ， 这 部 分 数据 是 
无 论 如 何 都 不 会 丢失 的 ，REDO 日 志 是 用 来 恢复 最 后 一 次 CHECKPOINT 到 宕 机 前 被 写 人 REDO 
日 志文 件 的 那 部 分 数据 。 由 于 REDO 日 志文 件 的 写 人 是 顺序 的 ， 所 以 无 论 这 部 分 数据 被 写 入 到 
一 个 文件 还 是 多 个 文件 ， 都 不 影响 数据 的 恢复 。 因 此 可 以 看 出 ，REDO 日 志文 件 的 大 小 和 服务 器 
宕 机 丢失 数据 的 数量 是 无 关 的 。 

通过 前 面 的 分 析 我 们 应 该 已 经 了 解 到 ， 在 绝 大 多 数 情况 下 ， 加 大 REDO 日 志文 件 的 大 小 并 
不 会 增加 数据 丢失 的 风险 。 因 此 我 们 在 考虑 REDO 日 志文 件 大 小 的 时 候 ， 基 本 上 可 以 忽略 数据 
丢失 问题 。 

不 过 在 某 些 情况 下 ， 在 需要 加 大 REDO 日 志文 件 时 ， 需 要 注意 下 列 问题 。 一 是 在 有 数据 保护 
的 情况 下 ， 为 了 减少 故障 切换 时 的 数据 丢失 量 ， 不 宜 将 REDO 日 志文 件 设 置 得 过 大 。 另 外 ， 如 果 
存在 CDC 或 者 流 复制 下 游 捕获 的 环境 ， 就 需要 考虑 REDO 日 志文 件 大 小 和 捕获 延 时 的 关系 问题 。 

很 多 DBA 都 认为 ， 应 该 尽 可 能 地 保证 REDO 日 志 切 换 的 时 间 不 低 于 10 分 钟 或 20 分 钟 。 如 
果 日 志 切 换 间隔 太 低 ， 就 要 考虑 加 大 REDO 日 志文 件 的 大 小 。 事 实 上 ， 这 里 并 没有 任何 铁 律 ， 
只 要 日 志 切 换 没有 对 系统 的 性 能 和 安全 产生 严重 的 影响 , 那么 哪怕 1 分 钟 切换 2 次 日 志 又 有 什么 
关系 呢 ? 
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5.2.5 ”事务 提交 和 回 滚 的 过 程 


以 前 有 人 在 面试 DBA 时 经 常会 问 ，1 万 行 记录 的 提交 和 1 行 记 录 的 提交 在 速度 上 是 否 相 同 。 
要 想 回 答 这 个 问题 ， 就 需要 了 解 Oracle 提交 的 机 制 ， 本 节 老 白 就 和 大 家 一 起 来 讨论 这 种 机 制 。 

提交 (COMMIT ) 操作 的 内 部 处 理 过 程 其实 很 简单 。Oracle 服务 进程 使 用 一 种 快速 提交 机 制 
来 确保 提交 的 变化 已 经 被 Oracle 数据 库 接受 , 这 样 , 即使 在 实例 故障 时 也 能 够 通过 内 部 机 制 来 恢 
^i . Oracle 服务 进程 在 执行 一 个 事务 时 会 不 断 地 修改 数据 ,将 产生 的 REDO 信息 写 人 日 志 缓 冲 区 ， 
mi LOG WRITER 进程 (LGWR ) 则 负责 不 断 地 将 日 志 缓 冲 区 中 的 数据 写 入 REDO 日 志文 件 。 不 
管 这 个 事务 修改 的 数据 块 是 否 已 经 存盘 ， 只 要 REDO 日 志 信 息 存 盘 了 ， 那 么 我 们 就 认为 这 个 数 
据 也 已 经 完成 了 存盘 。 因 为 即便 此 时 数据 库 实例 发 生 故 障 , 下 一 次 数据 库 实例 启动 时 也 可 以 根据 
REDO 日 志文 件 里 的 内 容 进 行 恢复 。 当 事务 提交 的 时 候 ，Oracle 服务 器 会 为 这 个 事务 分 配 一 个 
SCN. 根据 这 个 SCN， 服 务 进程 会 产生 一 个 提交 记录 ， 该 记录 包含 了 SCN。 然 后 提交 记录 被 写 
Л REDO 日 志 缓 冲 区 ， 此 时 服务 进程 就 需要 LGWR 进程 “帮忙 ”了 。 它 会 通知 并 激活 LGWR 进 
程 ， 后 者 将 日 志 缓冲 区 中 的 数据 写 和 人 REDO 日 志文 件 。 在 LGWR 进程 完成 写 和 之前， 服务 进程 
会 等 待 LOG FILE SYNC 事件 。 在 LGWR 进程 将 未 写 人 REDO 日 志文 件 的 该 提交 记录 之 前 ( 包 
含 该 记录 ) 的 所 有 REDO 日 志 绥 冲 区 都 写 人 REDO 日 志文 件 后 ， 服 务 进程 就 认为 提交 已 经 完成 
T, CAM TWO TASK 通信 机 制 通知 客户 端 “本 事务 已 经 提交 完成 ， 这 些 数据 不 会 丢失 了 "”。 
通知 信息 发 出 后 , 实际 上 本 次 事务 并 没有 彻底 完成 ， 此 时 服务 进程 还 有 很 多 的 工作 要 做 ， 比 如 释 
放 锁 资源 、 清 理 ITL 等 。 不 过 这 些 工作 都 可 以 稍 后 再 进行 ， 客户 端 已 经 收 到 了 事务 提交 完成 的 信 
息 ， 可 以 继续 其 他 的 工作 了 。 

5-1 就 是 事务 提交 过 程 的 示意 图 ， 这 个 图 来 自 OCP 培训 讲义 ， 这 里 老 白 偷 个 懒 ， 直 接 引 
用 如 下 。 


数据 库 高 
速 缓冲 区 


服务 器 进程 
控制 文件 
数据 文件 REDO H 


数据 库 志文 件 
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图 5-1 中 ， 第 一 步 是 服务 器 进程 将 提交 记录 写 人 REDO 日 志 缓 冲 区 ， 第 二 步 是 LGWR 进程 
将 相关 的 REDO ERSA REDO 日 志文 件 ， 第 三 步 是 服务 器 进程 将 提交 完成 的 消息 通知 用 户 进 
程 ， 第 四 步 是 服务 器 进程 继续 进行 后 续 处 理 。 从 上 面 的 图 中 我 们 可 以 看 出 ,决定 提交 操作 速度 的 
因素 实际 上 是 前 面 三 个 步骤 ， 其 中 第 一 步 和 第 三 步 基本 相同 ， 唯 一 的 区 别 是 第 二 步 LGWR 进程 
将 日 志 缓冲 区 写 和 人 REDO 日 志文 件 的 等 待 时 间 。 如 果 REDO 日 志 缓 冲 区 中 的 数据 积压 不 多 ， 那 
么 这 个 时 间 几 乎 可 以 忽略 不 计 ， 一 般 在 1 ~ 4ms。 如 果 REDO НА PAK Т RAW, 
BBA LOG FILE SYNC 等 待 的 时 间 就 会 略 长 一 些 ， 不 过 在 系统 IO 性 能 较为 正常 的 时 候 ， 这 个 等 
待 一 般 在 10ms 以 内 。 因 此 我 们 可 以 说 ， 无 论 事 务 大 小 ， 其 提交 的 速度 基本 上 相差 无 几 。 

IK, XTE (ROLLBACK ) 操作 ， 就 没 这 么 简单 了 ， 因 为 它 需 要 将 已 经 修改 的 数据 
恢复 到 修改 前 的 状态 , 因此 回 滚 操作 会 因为 事务 的 大 小 不 同 而 产生 很 大 的 差异 。 一 个 修改 了 数 百 
万 记录 的 事务 ， 回 滚 操作 可 能 需要 数 分 钟 ， 甚 至 几 十 分 钟 。 


5.3 REDO 优化 
我 们 在 学 习 REDO 日 志 的 基本 原理 和 算法 时 ， 一 个 很 重要 的 目的 就 是 为 了 进行 相关 的 优化 


工作 -REDO 的 优化 实际 上 要 从 两 个 角度 去 考虑 ,一 个 是 如 何 让 应 用 尽 可 能 减少 КЕРО 的 产生 量 ， 
另外 一 个 是 如 何 加 快 REDO 日 志 存 盘 的 速度 。 首 先 ,我 们 来 分 析 如 何 减 少 REDO 日 志 的 产生 量 。 


5.3.1 BULK 操作 能 减少 REDO 吗 


记得 10 多 年 前 ， 老 白 为 电信 开发 计 费 账 务 系统 时 ， 电 信 的 计 费 系统 应 该 算是 “海量 ”数据 
处 理 系统 了 。 一 个 本 地 网 可 能 拥有 50 万 电话 用 户 ， 其 中 20 ~ 30 万 用 户 是 有 长 话 业 务 权 限 的 ， 这 
些 用 户 每 个 月 可 能 会 产生 500 万 以 上 的 话 单 。 每 个 月 底 如 何 处 理 这 些 话 单 就 是 一 个 很 大 的 挑战 。 
1999 年 ， 电 信和 总 局 发 布 了 电信 账 务 系统 业务 规范 ， 并 且 要 求 各 个 开发 商 将 其 开发 的 账 务 系统 统 
一 拿 到 电信 总 局 去 测试 ， 测 试 通过 的 才能 够 获得 入 网 许可 。 在 参加 测试 的 60 多 家 企业 中 ， 老 白 
设计 的 系统 虽然 用 户 界面 比较 丑陋 (C 当时 老 白 的 公司 一 共 也 就 七 八条 “ 枪 ”， 整 个 开发 团队 只 有 
7 个 人 ， 因 此 UI 方面 和 其 他 动 轻 几 十 人 开发 团队 的 公司 是 没 法 比 的 )， 不 过 在 整个 账 务 处 理 的 性 
能 上 是 首届 一 指 的 ,在 包含 50 万 长 话 用 户 、500 万 话 单 记录 的 账 务 处 理 中 , 总 耗 时 只 有 4 小 时 多 ， 
拿 到 了 第 一 名 ， 而 第 二 名 的 成 绩 是 6 个 半 小 时 ， 第 三 名 的 成 绩 就 已 经 是 10 小 时 开外 了 。 当 时 老 
白 能 够 胜出 的 法 宝 有 两 个 : 一 个 是 将 50 万 用 户 资料 一 次 性 载 入 内存 ， 在 内 存 中 通过 B 树 结 构 保 
f£; 第 二 个 就 是 使 用 了 BULK 操作 。 后 来 老 白 和 第 二 名 的 公司 进行 了 沟通 ， 得 知 他 们 相似 的 地 
方 是 也 做 了 50 万 用 户 资料 的 预 装载 ， 但 是 没有 使 用 BULK 操作 。 

BULK 插入 操作 比 普 通 插入 操作 的 速度 要 快 很 多 ,这 一 点 是 很 多 使 用 过 BULK 操作 的 人 都 了 
解 的 , 不 过 为 什么 BULK 操作 会 比较 快 呢 ? Oracle 官方 的 说 法 是 , 进行 BULK 操作 的 时 候 , USER 
进程 和 SQL 引擎 的 交互 次 数 会 大 大 减少 ， 因 此 BULK 操作 有 较 好 的 性 能 。 老 白 也 一 直 认 同 这 个 
观点 ， 不 过 有 一 点 疑惑 的 是 ，BULK 操作 和 普通 操作 的 差异 仅仅 在 于 和 SQL 引擎 的 交互 次 数 上 
що 难道 BULK 操作 是 一 次 性 向 SQL 引擎 提交 一 个 SQL, SQL 引擎 内 部 处 理 BULK 操作 时 是 将 
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整个 数组 还 原 为 若干 条 记录 去 插入 的 吗 ? 还 是 说 BULK 插入 在 Oracle 内 部 处 理 过 程 中 有 一 些 独 

特 的 地 方 呢 ? 
在 研究 REDO OPCODE 的 时 候 , 老 白 发 现 了 一 些 蛛丝马迹 ,LAYER 11 是 针对 ROW ACCESS 

方面 的 ， 也 就 是 处 理 行 数据 的 。 在 LAYER 11 中 ， 有 这 样 一 些 操作 ， 如 代码 清单 5-2 所 示 。 


代码 清单 5-2 


Layer 11: 


Opcode 
Opcode 
Opcode 
Opcode 
Opcode 
Opcode 
Opcode 
Opcode 
Opcode 
Opcode 


Opcode 
Opcode 
Opcode 


m 


кә «oO со — сэ Un & WP 


Row Access - 


Interpret 


Drop Row Piece 


KCOCODRW 


[kdocts. h] 


Undo Record (Undo) 
Insert Row Piece 


Lock Row Piece 
Update Row Piece 


Overwrite Row Pi 
Manipulate Firs 
Change Forwardin 
: Change the Clus 
: Set Key Links 


ece 

Column (add or delete the 1rst column) 
g address 

er Key Index 

change the forward & backward key links 


on a cluster key) 
Quick Multi-Insert 


Quick Multi-De 


ete 


Toggle Block Header flags 


我 们 注意 到 , 11.11 的 定义 为 Quick Multi-insert, 11.12 为 Quick Multi-Delete , 这 两 个 OPCODE 


是 不 是 有 可 能 和 BULK 操作 有 关 呢 ?我 们 来 做 一 个 实验 ， 首 先 创建 一 张 测试 表 ， 如 代码 清单 5-3 


6), 


所 示 。 
代码 清单 5-3 

drop table sm histable0101 

CREATE TABLE SM HI STABLEO101 

( 
SM ID UMBER( 10) 
SM SUBI D UMBER( 3 
SERVICE TYPE VARCHAR2 
ORGTON UMBER( 3 
ORGNPI UMBER( 3 
ORGADDR VARCHAR2 
DESTTON UMBER( 3 
DESTNPI UMBER( 3 
DESTADDR VARCHAR2 
PRI UMBER( 3 
PID UMBER( 3 
SRR UMBER( 3 
DCS UMBER( 3 
SCHEDULE VARCHAR2 
EXPIRE VARCHAR2 
FINAL VARCHAR2 
SM_STATUS NUMBER( 3 
ERROR_CODE NUMBER( 3 
UDL NUMBER( 3 


NOT NULL, 
NOT NULL, 


NOT NULL, 


NOT NULL, 
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SM_TYPE UMBER 
SCADDRTYPE UMBER 
SCADDR VARCHA 
OMSCADDRTYPE UMBER 
OMSCADDR VARCHA 
TMSCADDRTYPE UMBER 
TMSCADDR VARCHA 
SCHEDULEMODE UMBER 
UD VARCHA 
D_HI NT UMBER 
DELIVERCOUNT UMBER 
L2CACHE UMBER 
L2CACHEWRI TECOUNT UMBER 
SERVI CE UMBER 
EWORGADDRESS VARCHA 
EWDESTADDRESS VARCHA 


|; 
然后 创建 两 个 存储 过 程 


REDO! 和 REDO2， 分 别 用 于 普通 捐 
代码 清单 5-4 和 代码 清单 5-5 所 示 。 


10), 
3 
R2 
3 
R2 
3 
R2 
3), 
R2(255), 
10) 
10), 
10), 
10), 
10), 
R2(21), 
R2(21) 


21), 
21), 


Уй, 


NOT NULL, 


入 操作 和 BULK 插入 操作 ， 如 


代码 清单 5-4 
create or replace procedure redol is 
TYPET SM ID IS TABLE OF NUMBER( 10) INDEX BY BI NARY | NTEGER 
TYPE T SM SUBID IS TABLE OF NUMBER( 3) INDEX BY BI NARY | NTEGER 
TYPE T ORGADDR IS TABLE OF VARCHAR2(21) INDEX BY BINARY | NTEGER 
TYPE T DESTADDR IS TABLE OF VARCHAR2(21) INDEX BY ВІ NARY | NTEGER 
TYPE T | D HI NT IS TABLE OF NUMBER( 10) INDEX BY BI NARY | NTEGER 
V SM ID T SM ID; 
V SM SUBI D T SM SUBI D; 
V ORGADDR T ORGADDR 
V DESTADDR T DESTADDR 
V | D HI NT T |D HI NT; 
| INTEGER; 
VREDOI TEGER; 
vredo2 integer 
BEGIN 
FOR | 1.. 2000 
LOOP 
V SM ID(I1): =l; 
V SM SUBI D(1): 212; 
V ORGADDR(IJ:z'444555565' 
V DESTADDR(I):2'555555' 
V | D HIENT(I): =l; 
END LOOP; 
select value into vredol from v$sysstat where name = 'redo size' 
FOR N 1..2000 LOOP 
NSERT INTO SM НІ STABLEO101 (SM ID, SM SUBI D, ORGADDR, DESTADDR, ID HI NT) VALUES 
V SM ID(I1), V SM SUBID(I),V ORGADDR(I),V DESTADDR(IJ),V ID HI NT(I)); 
END LOOP; 
COMMI T; 
commit; 
select value into vredo2 from v$sysstat where name = 'redo size' 
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select value into vredo2 from v$sysstat where name = 'redo size' 
dbms output.put line('redo size:'||to_char(vredo2-vredol)); 
END; 
| 
代码 清单 5-5 
create or replace procedure redo2 is 
TYPET SM ID S TABLE OF NUMBER( 10) INDEX BY BI NARY | NTEGER 
TYPE T SM SUBID 15 TABLE OF NUMBER( 3) INDEX BY BI NARY | NTEGER 
TYPE T ORGADDR IS TABLE OF VARCHAR2(21) INDEX BY BINARY | NTEGER 
TYPE T DESTADDR IS TABLE OF VARCHAR2(21) INDEX BY BINARY | NTEGER 
TYPE T ID HI NT IS TABLE OF NUMBER( 10) INDEX BY BI NARY | NTEGER 
V SM ID T SMID; 
V SM SUBI D T SM SUBI D 
V ORGADDR T ORGADDR 
V DESTADDR T DESTADDR 
V | D HI NT T |D HI NT; 
| | NTEGER; 
VREDOI TEGER; 
vredo2 integer 
n integer 
BEGIN 
n: =2000; 
FOR | IN 1.. N 
LOOP 
V SM ID(I): =l; 
V SM SUBI D(1): 212; 
V_ORGADDR(1): =' 444555565'; 
V DESTADDR(IJ:2'555555' 
V | D HIENT(I): =l; 
END LOOP; 
select value into vredol from v$sysstat where name - 'redo size' 
FORALL | IN 1..N 
NSERT INTO SM НІ STABLEO101 (SM I D, SM SUBI D, ORGADDR, DESTADDR, 10 HI NT) VALUES 
V SM ID(I)J, V SM SUBID(I), V ORGADDR(I),V DESTADDR(IJ),V ID HI NT(I)) 
COMMI T; 
commi t; 
select value into vredo2 from v$sysstat where name = 'redo size' 
select value into vredo2 from v$sysstat where name - 'redo size' 
dbms output.put line('redo size:'||to_char(vredo2-vredol)); 
END; 


I 
然后 执行 代码 清单 5-6 所 示 的 测试 。 


代码 清单 5-6 


set serveroutput on 

truncate table sm histable0101; 

select max(ktuxescnw * power(2, 32) + ktuxescnb) from x$ktuxe 
exec redol; 
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select max(ktuxescnw * power(2, 32) + ktuxescnb) from x$ktuxe; 


truncate table sm histable0101; 

select max(ktuxescnw * power(2, 32) + ktuxescnb) from x$ktuxe; 
exec redo2; 
select max(ktuxescnw * power(2, 32) + ktuxescnb) from x$ktuxe; 


测试 结果 如 下 : 


Table truncated. 


SQL» 
MAX( KTUXESCNW* POWER( 2, 32) *KTUXESCNB) 


87596111 


SQL» redo size:707356 
PL/SQL procedure successfully completed. 


SQL» 
MAX( KTUXESCNW* POWER( 2, 32) *KTUXESCNB) 


87596151 


SQL» truncate table sm histable0101; 

select max(ktuxescnw * power(2, 32) + ktuxescnb) from x$ktuxe; 
exec redo2; 

select max(ktuxescnw * power(2, 32) + ktuxescnb) from x$ktuxe; 


Table truncated. 


SQL» 
MAX( KTUXESCNW* POWER( 2, 32) *KTUXESCNB) 


87596178 
SQL» redo size: 138728 
PL/SQL procedure successfully completed. 


SQL» 
MAX( KTUXESCNW* POWER( 2, 32) *KTUXESCNB) 


87596195 

从 测试 的 结果 来 看 ， 使 用 普通 插入 操作 产生 了 707356B 的 REDO 日 志 ， 而 使 用 BULK 插入 
操作 只 产生 了 138728B 的 REDO Hak, REDO 日 志 产 生 量 不 到 正常 水 平 的 /5。 看 样子 BULK fff 
入 在 Oracle RDBMS 内 部 的 操作 是 完全 不 同 的 ， 应 该 是 采用 了 前 面 所 猜测 的 QUICK 
MULTI-INSERT 操作 。 我 们 可 以 通过 转 储 REDO 日 志 来 验证 一 下 : 
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SQL» alter systemdump logfile '/opt/oracle/oradata/orcl/redo01.log' scn min 87596178 
scn max 87596195 


System altered. 
转 储 出 的 REDO 信息 如 下 : 


CHANGE #2 TYP:0 CLS:18 AFN:7 DBA:0x01c007f2 08):4294967295 SCN:0x0000.05389bf0 
SEQ: 2 0P:5.1 
ktudb redo: siz: 396 spc: 5858 flg: 0x0012 seq: Ox2aba rec: 0x11 
xid: 0х0001. 021. 00005510 
ktubl redo: slt: 33 rci: 0 opc: 11.1 objn: 122951 objd: 122956 tsn: 0 
Undo type: Regular undo Begin trans Last buffer split: No 
Temp Object: No 
Tablespace Undo: No 
0x00000000 prev ctl uba: 0x01c007f2.2aba. Of 
prev ctl max cmt scn: | 0x0000.05388alf prev tx cmt scn: 0х0000. 05388а26 
txn start scn: Oxffff.ffffffff logon user: 0 prev brb: 29362160 prev bcl: 0 
KDO undo record 


KTB Redo 

0p: 0x03 ver: 0x01 

0p: Z 

KDO Op code: QMD row dependencies Disabled 


ype: XA flags: 0x00000000 Баба: 0x00406482 hdba: 0x00406481 
i: 1 ispac: 0 maxfr: 4863 
0 lock: 0 nrow: 131 

: 0 


чо co ч сэ Un Ф оо nO ка c 
чо co —1 сэ Un > оого ка 


t i 
t[10]: 10 
UTI 


从 上 述 信息 来 看 , UNDO 的 数据 也 和 普通 的 插 和 人 操作 不 同 , 是 批量 方式 的 , 同一 个 数据 块 中 
的 所 有 记录 都 产生 在 同一 个 UNDO 的 CHANGE VECTOR 中 。 接 下 来 ,我 们 再 来 分 析 代 码 清单 
5-7 所 示 的 数据 。 
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代码 清单 5-7 


CHANGE £3 TYP:0 CLS: 1 AFN:1 DBA:0x00406482 0BJ:122956 SCN:0x0000.05389c94 SEQ: 3 


0P:11.11 


op: 0x01 ver: 0x01 

op: F xid: 0x0001.021.0000551d uba: 0x01c007f2.2aba. 11 

KDO Op code: QMI row dependencies Disabled 

xtype: XA flags: 0x00000000 баба: 0x00406482 hdba: 0x00406481 
itli: 1 ispac: 0 maxfr: 4863 

tabn: O lock: 1 nrow: 131 
S 


ot[0]: 0 
tl: 53 fb: --H-FL-- 10: 0x0 cc: 29 
со 0: [| 2 c1 02 
C0 Is cl 0d 
со 2: *NULL* 
C0 3: *NULL* 
C0 4: *NULL* 
C0 5: [9 34 34 34 35 35 35 35 36 35 
C0 6: *NULL* 
C0 7: *NULL* 
C0 8: [ 6 35 35 35 35 35 35 
со 9: *NULL* 
col 10: *NULL* 
col 11: *NULL* 
col 12: *NULL* 
col 13: *NULL* 
col 14: *NULL* 
col 15: *NULL* 
col 16: *NULL* 
col 17: *NULL* 
col 18: *NULL* 
col 19: *NULL* 
col 20: *NULL* 
col 21: *NULL* 
col 22: *NULL* 
col 23: *NULL* 
col 24: *NULL* 
col 25: *NULL* 
col 26: *NULL* 
col 27: *NULL* 
col 28: [ 2 cl 02 
slot[1]: 1 


tl: 53 fb: --H-Fl-- 10: 0x0 cc: 29 

可 以 看 出 ， 这 里 确实 使 用 了 OP CODE:11.11，BULK 搬 和 人 操作 使 用 了 批量 数据 提 
此 其 性 能 才能 够 远 高 于 单条 记录 操作 。 在 我 们 以 往 进 行 的 测试 中 ,BULK 操作 一 般 者 
快 1 倍 以 上 ， 有 时 甚至 能 够 达到 2 倍 以 上 。 


和 机制， 
了 比 单条 操作 


在 REDO LAYER 11 中 ， 大 家 也 许 会 发 现 一 个 问题 ，11.11 是 MULTEINSERT, 11.12 是 
MULTI-DELETE, ， 唯 独 缺 少 了 MULTILUPDATE , 难道 BULK 更 新 操作 的 实现 机 制 和 BULK 插入 


操作 有 所 不 同 吗 ? 我 们 通过 一 个 实验 来 看 看 BULK 更 新 是 否 能 够 减少 REDO 的 产生 量 。 通 过 简 
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单 地 修改 REDO1、REDO2 两 个 存储 过 程 ， 生 成 REDOU1、REDOU2 这 两 个 存储 过 程 : 


create or replace procedure redoul is 


TYPET SM ID IS TABLE OF NUMBER( 10) INDEX BY BI NARY | NTEGER 
TYPE T SM SUBID 15 TABLE OF NUMBER( 3) INDEX BY BI NARY | NTEGER 
TYPE T ORGADDR IS TABLE OF VARCHAR2(21) INDEX BY BI NARY | NTEGER 
TYPE T DESTADDR IS TABLE OF VARCHAR2(21) INDEX BY BI NARY | NTEGER 
TYPE T | D HI NT IS TABLE OF NUMBER( 10) INDEX BY BI NARY | NTEGER 
V SM ID T SMID; 
V SM SUBID T SM SUBI D; 
V ORGADDR T ORGADDR 
V DESTADDR T DESTADDR 
V | D HI NT T |D HI NT 
| | NTEGER; 
VREDOI TEGER; 
vredo2 integer 
BEGIN 
FOR | 1.. 2000 
LOOP 
V_SM_ID(I): =l; 
V SM SUBI D(1): 212; 
V ORGADDR(IJ:z' 111111'; 
V_DESTADDR(I): ='2222'; 
V 1D HIENT(I): =i; 
END LOOP; 
select value into vredol from v$sysstat where name - 'redo size' 
FOR | IN 1..2000 LOOP 
update SM HI STABLEO101 SET ORGADDR=V_ORGADDR(!) WHERE 10 HINTzV ID HI NT(I) 


END LOOP; 
COMMI T; 
commi t; 
select value into vredo2 from v$sysstat where name = 'redo size' 
select value into vredo2 from v$sysstat where name - 'redo size' 
dbms output.put line('redo size:'||to_char(vredo2-vredol)); 

END; 


I 


create or replace procedure redoU2 is 


TYPET SM ID 15 TABLE OF NUMBER( 10) INDEX BY BI NARY | NTEGER 
TYPE T SM SUBID IS TABLE OF NUMBER( 3) INDEX BY BI NARY | NTEGER 
TYPE T ORGADDR 15 TABLE OF VARCHAR2(21) INDEX BY BI NARY | NTEGER 
TYPE T DESTADDR 15 TABLE OF VARCHAR2(21) INDEX BY BI NARY | NTEGER 
TYPE T | D HI NT IS TABLE OF NUMBER( 10) INDEX BY BI NARY | NTEGER 
V SM ID T SMID; 

V SM SUBI D T SM SUBI D 

V ORGADDR T ORGADDR 

V DESTADDR T DESTADDR 

V | D HI NT T |D HI NT; 

| I NTEGER; 

VREDOI TEGER; 

vredo2 integer 


n integer 
BEGIN 
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n: 22000; 
FOR | IN 1.. N 
LOOP 
V SM ID(I): =l; 
V SM SUBI D(1): 7212; 
V ORGADDR(IJ:z' 111111'; 
V DESTADDR(I):-2'2222'; 
V Тр HIE NT(I): =l; 
END LOOP; 
select value into vredol from v$sysstat where name = 'redo si 
FORALL | IN 1..N 
update SM HI STABLEO101 SET ORGADDR-V ORGADDR(I) WHERE ID Н 
COMMI T; 
commit; 
select value into vredo2 from v$sysstat where name = 'redo s 
Select value into vredo2 fromv$sysstat where name = 'redo s 
dbms_output.put_line('redo size:'||to_char(vredo2-vredol)); 
END: 
| 
然后 执行 下 面 的 过 程 : 
select max(ktuxescnw * power(2, 32) + ktuxescnb) from x$ktuxe 
exec redoul; 
select max(ktuxescnw * power(2, 32) + ktuxescnb) from x$ktuxe 
select max(ktuxescnw * power(2, 32) + ktuxescnb) from x$ktuxe 
exec redou2 
select max(ktuxescnw * power(2, 32) + ktuxescnb) from x$ktuxe 


redo size:578904 


PL/SQL procedure successfully completed 


SQL» 


MAX( KTUXESCNW* POWER( 2, 32) +KTUXESCNB) 


87608317 


SQL» SQL» SQL» 
MAX( KTUXESCNW* POWER( 2, 32) *KTUXESCNB) 


87608317 


SQL» redo size:571168 


PL/SQL procedure successfully completed 


SQL> 


MAX( KTUXESCNW* POWER( 2, 32) +KTUXESCNB) 


87610350 


T=V_ID_HINT(I); 


ize'; 
ize'; 
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从 上 面 的 结果 来 看 , 两 种 操作 产生 的 REDO 量 是 十 分 接近 的 , 因此 BULK 更 新 操作 在 REDO 
方面 并 没有 很 大 的 改善 。 通 过 转 储 REDO 日 志 ， 我 们 进一步 验证 这 个 测试 结 
CHANGE #3 TYP:2 CLS: 1 AFN:1 DBA:0x00406482 0BJ:122959 SCN:0x0000.0538cbfd SEQ: 1 


0P:11.5 

KTB Redo 

op: 0x11 ver: 0x01 

op: F xid: 0x0003.011.0000724a uba: 0х00800ас1. 320с. le 

Block cleanout record, scn: 0x0000.0538cbff ver: 0x01 opt: 0x02, entries follow.. 


itli: 2 flg: 2 scn: 0x0000.0538cbf d 

KDO Op code: URP row dependencies Disabled 

xtype: XA flags: 0x00000000 Баба: 0x00406482 hdba: 0x00406481 
itli: 1 ispac: 0 maxfr: 4863 

Карп: 0 slot: 0(0х0) flag: Ox2c lock: 1 скіх: 191 

ncol: 29 nnew: 1 size: 0 

col 5: [6] 31 31 31 31 31 31 


我 们 在 这 里 看 到 了 OP CODE 11.5， 这 是 一 个 正常 的 单行 更 新 操作 。 也 就 是 说 ， 对 于 ВЕРО 
产生 而 言 ，FORALL 更 新 并 不 会 批量 产生 REDO 信息 ， 和 普通 的 更 新 处 理 没有 区 别 。FORALL 
更 新 在 性 能 上 的 提升 可 能 仅 限 于 SQL 引擎 之 间 的 交互 而 已 。 


5.3.2 ”如 何 优化 LOG FILE SYNC 等 待 事件 


在 一 个 提交 十 分 频繁 的 系统 中 ， 我 们 经 常会 看 到 LOG FILE SYNC 等 待 事件 出 现在 ТОР 
EVENTS 中 。 这 种 情况 下 ， 可 能 就 需要 针对 LOG FILE SYNC 等 待 事件 进行 优化 了 。 

首先 我 们 会 看 一 下 这 个 等 待 事件 的 平均 等 待 时 长 。 正常 情况 下 平均 等 待 时 间 不 会 超过 10ms， 
如 果 等 待 时 间 太 长 ， 那 说 明 LOG WRITER 每 次 写 入 的 时 间 过 长 ， 如 果 能 够 优化 REDO 日 志文 件 
的 存储 , 使 之 存放 到 更 快 的 磁盘 上 ， 就 可 以 减少 这 个 等 竺 事件 的 单 次 等 待 时 间 。 不 过 理论 上 能 够 
实现 的 事情 往往 是 最 不 可 靠 的 , 系统 管理 员 可 能 会 和 你 说 , 目前 的 存储 优化 已 经 做 得 好 到 不 能 
好 了 ， 想 要 存放 到 更 快 磁 盘 上 的 可 能 性 几乎 不 存在 。 也 许 你 很 幸运 ， 当 前 的 REDO 日 志 是 存放 
在 RAID5 上 的 ， 而 存储 上 正好 有 个 磁盘 组 是 RAID 10 的 ， 而 且 可 以 划 些 空间 给 你 ， 这 样 就 可 以 
通过 提升 REDO 日 志 写 性 能 来 优化 这 个 等 待 事件 了 。 

但 如 果 不 凑 巧 ,我 们 无 法 通过 优化 REDO 日 志 的 IO 性 能 来 解决 这 个 问题 ,或 者 优化 了 REDO 
日 志 的 VO 性 能 后 还 是 无 法 达到 我 们 的 预期 ， 那 么 该 如 何 处 理 呢 ? 有 经 验 的 РВА 可 能 会 建议 加 
大 日 志 缓 冲 区 。 提 到 加 大 日 志 缓 冲 区 ， 可 能 有 些 朋 友 就 会 感到 疑惑 了 ，REDO 日 志文 件 写 等 待 时 
间 长 怎么 会 和 日 志 缓 冲 区 直接 关联 起 来 呢 ? 实际 上 这 个 问题 解释 起 来 一 点 也 不 难 , 如 果 数 据 文件 
的 VO 性 能 有 问题 ,平均 单 块 读 的 等 待 时 间 偏 长 ,那么 可 以 通过 加 大 DB Cache 来 减少 IO 总 次 数 ， 
从 而 达到 优化 VO 的 效果 。 加 大 日 志 缓 冲 区 的 原理 也 是 一 样 的 ， 这 样 可 以 使 日 志 绥 冲 区 中 存储 更 
多 的 REDO 日 志 数 据 ， 从 而 减少 由 于 REDO 日 志 缓冲 区 不 足 而 产生 的 LGWR 写 操作 的 数量 ,使 
平均 每 次 写 人 REDO 日 志文 件 的 REDO 字 节 数 增加 ， 从 而 减少 REDO 的 IO 次 数 ， 进 而 达到 优 
化 LOG FILE SYNC 等 待 事件 的 目的 。 

如 果 上 述 两 种 方法 都 不 奏效 ， 又 该 如 何 处 理 呢 ?” 还 有 一 种 方法 , 就 是 减少 提交 的 次 数 。 如 果 
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提交 过 于 频繁 , 那么 无 论 怎样 优化 都 无 法 彻底 解决 问题 。 通 过 加 大 一 次 提交 记录 的 数量 , 减少 提 
交 批 次 ， 可 以 有 效 地 减少 LOG FILE SYNC 等 竺 时间。 采用 此 方法 就 意味 着 需要 对 应 用 进行 较 大 
的 调整 ， 甚 至 要 对 应 用 架构 做 出 修改 ， 这 种 修改 的 代价 将 十 分 巨大 。 

还 有 一 个 方案 可 以 优化 LOG FILE SYNC 事件 ,就 是 把 部 分 经 党 提交 的 事务 设置 为 异步 提交 。 
异步 提交 是 10g 版 本 引入 的 新 特性 ， 通 过 设置 COMMIT WRITE 参数 ， 可 以 控制 异步 提交 。 
COMMIT_WRITE 参数 的 默认 值 是 “IMMEDIATE,WAIT”， 可 以 将 其 设置 为 
“IMMEDIATE,NOWAIT” 来 实现 异步 提交 。 这 个 参数 支持 系统 级 设置 ， 也 支持 会 话 级 设置 。 

如 果 觉 得 设置 COMMIT_WRITE 参数 太 麻 烦 , 也 可 以 直接 使 用 COMMIT WRITE 命令 ,比如 ， 
COMMIT WRITE IMMEDIATE NOWAIT。COMMIT WRITE 的 语法 如 图 5-2 所 示 。 


IMMEDIATE WAIT 
NO WAIT 


图 5-2 


其 中 ,IMMEDIATE 表示 提交 时 LGWR 马上 开始 REDO 日 志 写 操作 ,而 BATCH 表示 提交 后 LGWR 
不 需要 马上 开始 写 REDO 日 志 , 可 以 按照 其 原 有 的 计划 启动 写 操作 。BATCH 可 以 让 REDO 日 志 
写 操作 更 加 滞后 ， 一 般 我 们 还 是 希望 尽快 写 人 REDO 日 志 数 据 ， 因 此 “IMMEDIATE,NOWAIT” 
是 较为 常用 的 优化 方案 。 

不 过 使 用 异步 提交 会 带 来 一 个 问题 。 从 REDO 日 志 的 基本 原理 来 看 ， 数 据 一 旦 提交 成 功 ， 

客户 端 就 可 以 认为 其 已 经 被 正常 存 人 数据 库 了 , 哪怕 实例 出 了 故障 ,这 些 数据 也 不 会 丢失 。 而 异 
步 提交 的 数据 ， 即 使 已 经 提交 成 功 ， 也 还 是 有 可 能 丢失 。 因 此 一 旦 数据 库 实例 有 故障 ， 采 用 异步 
提交 的 系统 需要 做 一 些 额外 的 校 验 和 处 理 , 清理 不 一 致 的 数据 , 重新 插入 刚才 由 于 异步 提交 而 丢 
失 的 数据 。 这 就 需要 应 用 对 当前 最 后 一 笔 提交 的 数据 进行 特殊 处 理 , 建立 校 验 机 制 和 错误 数据 处 
理 机 制 。 我 们 需要 在 应 用 层面 进行 一 些 特殊 的 设置 。 应 该 注意 的 是 , 那些 特别 重要 的 、 后 续 无 法 
重新 完全 补充 的 数据 不 适合 使 用 这 种 方法 。 
老 白 曾经 参加 过 一 个 项 目的 投标 工作 ， 客 户 在 进行 压力 测试 ， 而 测试 的 存储 系统 性 能 不 佳 ， 
REDO A EFE RAID 5 上 ， 一 旦 系统 负载 增加 到 800TPS，LOG FILE SYNC 的 等 待 就 十 分 严 
重 ， 这 也 成 为 系统 的 一 个 主要 瓶颈 。 由 于 仅仅 是 压力 测试 ， 实 际 生产 系 统 不 可 能 达到 800tps， 而 
且 实际 中 的 存储 系统 要 远 好 于 当前 的 测试 平台 。 但 由 于 目前 这 个 问题 的 存在 , 客户 的 很 多 测试 项 
目 无 法 完成 。 为 了 完成 本 次 测试 ， 老 白 就 建议 客户 使 用 异步 提交 。 采 用 异步 提交 后 ， 系 统 并 发 处 
理 能 力 明 显 提高 ， 最 终 完成 了 1200tps 的 测试 工作 。 

最 后 ， 老 白 要 说 的 是 ，LOG FILE SYNC 等 待 事件 是 十 分 关键 的 ， 我 们 在 数据 库 的 日 常 维护 
中 应 该 对 此 指标 建立 基线 ， 如 果 这 个 指标 有 异常 变化 , 一 定 要 尽快 分 析 并 解决 问题 。 一 旦 这 个 指 
标 恶 化 ， 可 能 导致 系统 性 能 急剧 下 降 ， 甚 至 会 导致 短暂 的 挂 起 。 去 年 ， 一 个 客户 的 系统 ， 平 时 


168 第 5 章 理解 REDO 日 志 


LOG FILE SYNC 的 指标 是 2 ~ 3ms。 在 一 次 巡 检 时 老 白 发 现 该 指标 增长 到 了 7ms， 当 时 在 这 检 报 
告 中 建议 客户 关注 这 个 指标 ,并 尽快 检查 存储 系统 和 操作 系统 ， 查 出 变 慢 的 原因 。 客 户 检查 了 存 
fü, 没有 发 现 故 障 ， 于 是 就 不 了 了 之 了 。 在 下 个 月 巡 检 的 时 候 ， 老 白 发 现 该 指标 增长 到 了 13ms， 
再 次 预警 ， 依 然 没 有 发 现 问 题 。 随 后 两 个 月 这 个 指标 一 直 持 续 恶 化 ， 增 长 到 了 20 多 毫秒 。 由 于 
前 面 几 个 月 的 检查 工作 没有 发 现 问题 , 而 目前 系统 也 还 是 很 正常 的 , 所 以 客户 也 就 没有 再 去 认真 
核查 。 终 于 有 一 天 , 系统 突然 挂 起 了 ,5 分 钟 后 才 恢 复 正 常 。 后 来 检查 原因 , 就 是 LOG FILE SYNC 
等 待 导致 的 。 根 据 老 白 的 建议 ， 客 户 从 头 到 尾 检 查 了 一 遍 ， 最 终 发 现 LVM 的 一 条 链 路 存在 闪 断 
现象 ， 修 复 了 链 路 后 ， 一 切 都 恢复 正常 了 。 

通过 上 面 的 案例 ， 我 们 要 吸取 教训 ， 如 果 LOG FILE SYNC 指标 有 所 恶化 ， 一 定 要 尽快 排查 
问题 的 根源 , 如 果 LOG FILE SYNC 的 等 待 时 间 持续 上 升 , 那么 系统 出 现 挂 起 的 可 能 性 也 在 增加 。 
尽快 找到 问题 的 原因 是 势 在 必 行 的 。 


5.3.3 SHUTDOWN ABORT 无 害 吗 


以 前 老 前 辈 一 直 教 育 我 们 ， 千 万 不 要 用 SHUTDOWN ABORT 命令 关闭 数据 库 ， 因 为 这 样 会 
使 数据 库 宕 机 。 这 个 观点 一 直 都 影响 着 我 ， 我 也 一 直 没 有 怀疑 过 “SHUTDOWN ABORT 有 害 ” 
这 一 说 法 ， 而 且 在 给 其 他 人 讲课 时 ， 也 把 这 个 观点 不 断 地 传递 给 一 批 又 一 批 新 的 DBA。 
直到 我 认真 研究 了 REDO 日 志和 数据 库 恢 复 的 原理 , 才 明 白 原 来 SHUTDOWN ABORT 并 不 
那么 可 怕 。 根 据 实例 恢复 的 原理 ,已 经 提交 的 数据 肯定 已 被 写 和 人 REDO 日 志文 件 了 ， 如 果实 例 
突然 宕 掉 ， 只 要 底层 的 存储 没有 出 现 故 障 ， 那 么 再 次 启动 的 时 候 ， 应 该 能 够 根据 REDO 日 志文 
件 进行 恢复 。 如 此 说 来 ，SHUTDOWN ABORT 应 该 是 无 害 的 。 

确实 ， 从 原理 上 看 ，SHUTDOWN ABORT 命令 的 确 不 会 导致 数据 库 损坏 ， 只 是 会 丢失 一 些 
当前 没有 存盘 的 数据 。 当 实例 再 次 启动 的 时 候 ，Oracle 可 以 根据 REDO 日 志 中 的 数据 ,重新 修改 
并 恢复 丢失 的 数据 。 

虽然 Oracle 的 REDO 机 制 可 以 确保 SHUTDOWN ABORT 不 会 对 正常 的 事务 数据 产生 影响 ， 
但 是 我 们 忽略 了 一 点 ，Oracle 数据 库 中 数据 文件 的 修改 ， 并 不 都 是 基于 事务 这 种 机 制 的 ， 还 有 一 
些 数据 的 修改 采取 了 特殊 的 方法 。 比 如 ， 各 种 位 图 的 维护 、 数 据 文件 扩展 等 。 我 们 使 用 
SHUTDOWN ABORT 命令 时 ， 如 果 恰 巧 有 这 样 的 操作 正在 进行 ,那么 下 次 数据 库 启 动 的 时 候 ， 
就 可 能 出 现 一 些 不 一 致 ， 甚 至 出 现 数据 库 实例 无 法 启动 的 情况 。 另 外 , 我 们 也 不 能 忽视 随处 都 可 
能 遇 到 的 Bugo 

所 以 , 虽然 从 基本 原理 上 来 说 ，SHUTDOWN ABORT 不 会 导致 数据 库 宕 机 ， 但 是 还 是 要 十 
分 谨慎 地 使 用 。 作 为 一 个 具有 近 20 年 工作 经 验 的 DBA， 老 白 在 这 方面 一 直 比 较 保守 。 在 关闭 
数据 库 之 前 ， 尽 可 能 做 几 次 CHECKPOINT ( ALTER SYSTEM CHECKPOINT )。 如 果 关 闭 过 程 
很 长 时 间 都 没有 完成 ， 就 应 该 先 考 虑 杀 掉 所 有 “LOCAL=NO” 以 及 其 他 “LOCAL=YES” 的 前 
台 进 程 ， 然 后 再 观察 是 否 能 够 正常 关闭 数据 库 。 可 以 使 用 下 面 的 命令 杀 掉 所 有 “LOCAL=NO” 
的 前 台 进 程 : 
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ps -ef|grep "LOCAL=NO" |awk '(print "kill -9 " $2)'|sh 
不 过 还 有 一 种 可 能 ， 即 便 杀 掉 了 所 有 的 应 用 进程 ， 数 据 库 还 是 无 法 关闭 。 比 如 ， 我们 可 能 
看 到 : 
Shutting down Instance (immediate) 
License high water mark = 12 
Thu Dec 8 18:43:16 1999 
alter database close normal 
Thu Dec 8 18:43:17 1999 


SMON: disabling tx recovery 
SMON: disabling cache recovery 


这 些 信息 显 示 SMON 已 经 结束 了 事务 层面 的 回 退 操作 , 关闭 了 cache 层面 的 恢复 , 也 就 是 说 
SMON 开始 进行 临时 段 回收 工作 了 。 如 果 系 统 中 有 大 量 需 要 回收 的 临时 段 , 那么 这 个 操作 可 能 会 
持续 很 长 时 间 。 这 时 关闭 数据 库 实例 (通过 SHUTDOWN ABORT ) 是 安全 的 ， 不 会 引起 数据 库 
故障 。 当 然 ， 用 户 也 可 以 继续 等 待 ， 直 到 SMON 完成 工作 。 不 过 SMON 可 能 会 由 于 某 种 原因 挂 
起 了 ， 在 等 待 了 很 长 时 间 后 还 是 这 种 状态 ， 这 时 可 以 果断 采取 SHUTDOWN ABORT 的 动作 。 在 
关闭 数据 库 的 过 程 中 ， 很 有 可 能 出 现 类 似 的 挂 起 现象 。 

在 做 关闭 操作 之 前 ， 如 果 用 户 已 经 关闭 了 应 用 或 者 杀 掉 了 所 有 的 用 户 进程 ， 并 且 完 成 了 
CHECKPOINT， 那 么 采用 SHUTDOWN ABORT 操作 的 风险 就 降 到 了 最 低 。 


5.3.4 关于 REDO 日 志 优 化 的 建议 


REDO 日 志 的 优化 其 实 并 不 难 , 随 着 Oracle 新 版 本 的 发 布 和 存储 技术 的 发 展 , REDO 日 志 的 
性 能 问题 越 来 越 少 。 一 般 来 说 ， 我 们 针对 REDO 日 志 的 优化 集中 在 几 个 方面 : 
口 REDO 日 志文 件 的 大 小 ; 
口 REDO 日 志 组 的 数量 ; 
О REDO 日 志 镜 像 ; 
口 REDO 日 志 存 储 的 性 能 ; 
о 日 志 缓 冲 区 的 设置 。 

REDO 日 志 切 换 是 一 种 开销 较 大 的 操作 ， 每 次 日 志 切 换 都 会 强制 进行 CHECKPOINT。 因 此 
尽 可 能 不 要 在 业务 高 峰 期 过 于 频繁 地 进行 日 志 切换 ， 这 样 对 于 系统 总 体 性 能 的 帮助 还 是 很 大 的 。 
Oracle 建议 日 志文 件 的 大 小 能 够 保证 日 志 切 换 的 时 间 在 20 分 钟 以 上 ， 但 实际 上 ， 这 在 很 多 大 型 
企业 级 应 用 系统 中 很 难保 证 。 很 多 企业 级 应 用 系统 的 REDO 日 志 产 生 量 很 大 ,哪怕 REDO НЕ 
文件 设置 为 2GB ,也 无 法 确保 高 峰 期 的 日 志 切 换 时 间 超 过 3 分 钟 ， 甚 至 有 的 连 1 分 钟 都 不 到 。 实 
际 上 ， 判 断 REDO 日 志文 件 大 小 是 否 足 够 的 主要 因素 并 不 仅仅 局 限于 日 志 切 换 的 时 间 ， 如 果 过 
于 频繁 的 日 志 切 换 并 没有 对 系统 性 能 和 稳定 性 产生 较 大 的 影响 , 那么 还 是 可 以 接受 的 。 从 Oracle 
10g 开始 ，Oracle 提供 了 一 个 REDO LOG SIZE ADVISORY 的 新 功能 ， 这 个 功能 可 以 提供 关于 
REDO 日 志文 件 大 小 的 建议 。 系 统 将 根据 高 峰 期 产生 REDO 的 数量 , 以 及 系统 日 志 切 换 的 时 间 间 
隔 ， 提 出 一 个 建议 值 ， 比 如 : 
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SQL» select optimal logfile size from v$lnstance_ recovery; 


OPTI MAL LOGFILE SIZE 


这 个 值 的 单位 是 兆 字 节 ， 也 就 是 说 ，Oracle 建议 REDO 日 志文 件 的 大 小 为 1954MB ， 而 当前 
系统 的 REDO 日 志文 件 大 小 是 1GB ， 建 议 值 约 为 当前 值 的 两 倍 。 这 个 建议 可 以 供 我 们 参考 ， 由 
于 当前 系统 并 未 由 于 CHECKPOINT fil log file switch 产生 较为 严重 的 问题 ，LOG FILE SYNC 等 
待 也 比较 正常 ， 因 此 当前 REDO 日 志文 件 的 大 小 可 以 暂时 不 做 调整 。 当 然 如 果 按 照 Oracle 的 建 
议 加 大 REDO 日 志文 件 ， 也 是 可 行 的 。 

对 于 绝 大 多 数 系统 来 说 , REDO 日 志 组 的 数量 不 直接 和 性 能 产生 关系 。 不 过 对 于 REDO 切换 
十 分 频繁 的 数据 库 , 比如 ,高 峰 期 1 分 钟 切换 一 次 甚至 不 到 1 分 钟 切换 一 次 的 数据 库 , 如 果 REDO 
日 志 组 的 数量 偏 少 , 将 会 导致 所 有 REDO 日 志 组 耗 尽 , 而 且 它们 都 处 于 活跃 ( active ) 状 态 ( REDO 
日 志文 件 中 包含 的 变化 量 的 SCN 还 大 于 CKTP SCN ), 那么 日 志 切 换 就 无 法 进行 ， 必 须 等 到 某 一 
组 REDOLOG 从 活跃 转 为 不 活跃 (inactive )， 才 能 继续 进行 日 志 切 换 。 这 时 ， 整 个 系统 的 修改 操 
作 都 处 于 挂 起 状态 ， 等 竺 日志 文件 切换 完成 (其 等 待 事件 就 是 LOG FILE SWITCH )。 如 果 碰 到 
这 种 情况 ， 就 必须 增加 REDO 日 志 组 的 数量 或 者 增加 REDO 日 志文 件 的 大 小 。 

REDO 日 志 的 成 员 (member) 数量 就 是 REDO 日 志文 件 镑 像 的 数量 。 默 认 情 况 下 ，Oracle 
的 每 个 REDO 日 志 组 会 有 两 个 成 员 。 这 种 配置 下 ,如 果 某 个 REDO 日 志文 件 损坏 ,另外 一 个 REDO 
日 志文 件 可 以 用 于 恢复 ， 不 会 导致 数据 库 宕 机 。 实 际 上 ， 使 用 REDO 日 志 镜 像 的 要 求 十 分 严格 ， 
在 最 为 严格 的 情况 下 , 不 同 的 成 员 不 能 存放 于 相同 的 卷 组 、 磁 盘 组 和 物理 硬盘 ,这 样 才 能 达到 最 
佳 的 容错 效果 。 不 幸 的 是 , 老 白 磁 到 的 所 有 系统 都 不 满足 这 个 条 件 ，90% 以 上 的 系统 REDO 日 志 
文件 是 在 同一 个 卷 组 中 分 配 的 。 一 旦 这 个 卷 组 出 现 故 障 , 那么 所 有 的 成 员 也 都 会 有 故障 ,这 完全 
违背 了 设置 多 个 镜像 的 初 囊 。REDO 日 志文 件 会 消耗 大 量 IO 资源 ， 因 此 REDO 日 志 镜 像 会 大 幅 
增加 系统 IO 开销 ， 也 就 是 说 ， 设 置 两 个 以 上 成 员 的 意义 并 不 是 很 大 ， 除 非 系统 的 可 用 性 要 求 特 
别 高 ， 且 IO 能 力 远 远 高 于 系统 负载 。 对 于 一 个 VO 性 能 存在 瓶颈 的 系统 ， 使 用 多 个 镜像 是 十 分 
“和 奢侈” 的， 取消 镜像 可 以 节省 大 量 的 VO 资源 ， 但 会 带 来 单 点 故障 。 在 这 种 环境 下 ， 如 何 权 衡 
好 系统 可 用 性 和 性 能 就 十 分 重要 了 。 

无 论 怎样 配置 ，REDO 日 志文 件 都 是 写 敏 感 的 文件 ， 其 写 VO 是 频繁 的 小 型 写 和 人 操作， 每 次 
写 人 的 数据 量 从 几 百 字 节 到 几 十 万 字 节 不 等 , 偶尔 也 有 一 些 大 的 写 人 操作 , 可 能 达到 几 兆 字 节 或 
ЛЭК. Ж REDO 日 志文 件 存 放 于 性 能 较 好 的 盘 是 十 分 必要 的 ， 最 好 将 其 存放 在 RAID 1+0 
的 设备 中 ，RAID 5 对 于 高 负载 的 系统 来 说 可 能 会 引起 一 些 性 能 问题 。 如 果 某 个 系统 的 IO 性 能 
存在 明显 的 问题 , 特别 是 存在 VO 热点 , 那么 将 REDO 日 志 迁 移 到 其 他 的 磁盘 组 ， 从 而 隔离 UO, 
是 比较 简单 的 优化 方法 。 

对 于 日 志 缓冲 区 和 REDO 日 志 VO 性 能 问题 的 关系 ， 很 多 РВА 可 能 都 会 党 得 有 些 迷 茫 。 确 
实 ， 在 这 方面 ， 互 联网 上 充斥 着 伪 科 学 。 顾 名 思 义 ， 日 志 缓冲 区 是 为 了 提高 REDO 日 志 写 性 能 
而 设计 的 缓冲 区 ， 系 统 产生 的 REDO 日 志 信 息 首 先 被 缓冲 在 日 志 缓 冲 区 中 ,等 LGWR 有 能 力 处 
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理 的 时 候 才 将 缓冲 区 中 的 REDO 日 志 信息 写 人 到 REDO 日 志文 件 中 。 这 样 就 避免 了 大 量 的 小 型 
写 操作 ， 可 以 将 小 型 的 REDO 日 志 片 段 组织 成 一 个 较 大 的 写 操作 ， 统 一 写 人 REDO 日 志文 件 。 
如 果 某 个 时 间 段 REDO 日 志 信息 的 产生 量 很 大 ，REDoO 日 志 产 生 的 速度 大 于 LGWR 5 Л REDO 
日 志 的 速度 , 那么 日 志 缓冲 区 中 的 数据 就 会 积压 。 当 积压 到 一 定 程 度 , 日 志 组 冲 区 就 可 能 被 撑 爆 。 
这 时 , 产生 REDO 的 会 话 就 会 增加 redo buffer allocation retries 计数 ， 这 个 操作 将 被 暂 时 挂 起 ,等 
待 日 志 缓冲 区 中 空闲 空间 的 出 现 。 因 此 在 一 个 REDO 日 志 生 成 量 很 大 的 系统 中 ( 比如 每 秒 产 生 
4MB ДЕ, E 10MB 以 上 的 系统 )， 可 能 需要 将 日 志 缓冲 区 设置 得 比较 大 ， 比 如 20MB , 30MB 
甚至 上 百 兆 字 节 。 关 于 日 志 3MB 就 没有 意义 的 言论 , 老 白 已 经 在 多 个 场合 批驳 过 了 ， 
завин 幅 去 讨论 


理解 UNDO 


UNDO 给 大 家 的 最 初 印 象 就 是 事务 的 回 滚 。 确 实 ，UNDO 实现 了 Oracle 数据 库 的 事务 回 滚 。 
实际 上 ， 回 滚 事务 只 是 UNDO 的 一 个 功能 ，UNDO 还 有 一 个 十 分 重要 的 功能 就 是 一 致 性 读 。 由 
于 UNDO 的 存在 ， 使 得 一 致 性 读 成 为 可 能 。 如 果 没 有 UNDO ,那么 要 实现 一 致 性 读 就 必须 将 读 
操作 定义 成 排他 性 的 ， 当 某 个 数据 被 读 之 前 , 不 允许 任何 对 该 数据 的 修改 操作 , 这样 会 大 大 降低 
并 发 操作 的 性 能 。 由 于 UNDO 的 存在 ,一 个 数据 的 前 映像 (pre image ) 可 以 被 存放 在 UNDO 表 
空间 中 ， 因 此 在 查询 时 ， 哪 怕 数 据 已 经 被 修改 了 ， 我 们 仍 可 以 从 UNDO 中 找到 某 个 时 间 点 的 前 
映像 ， 从 而 完成 一 致 性 读 。 

从 Oracle 9i 开始 ，UNDO 被 赋予 了 新 的 功能 一 一 闪 回 查询 。 闪 回 查 询 就 是 利用 UNDO 中 保 
存 的 前 映像 查询 以 前 的 数据 。 除 了 闪 回 查询 外 ,9%i 版 本 还 有 一 个 新 功能 ， 就 是 查询 某 个 时 间 段 内 
的 数据 变化 。 这 个 功能 实际 上 和 闪 回 查询 类 似 ， 都 是 通过 前 映像 来 实现 的 。 

早期 版 本 的 UNDO 管理 十 分 复杂 ，DBA 也 经 党 面临 UNDO 出 现 的 各 种 问题 ， 比 如 UNDO 
引起 的 性 能 问题 ， 以 及 著名 的 ORA-1555 错误 。 自 从 Oracle 9 引入 了 UNDO 自动 管理 后 ， 这 些 
问题 都 变 得 简单 了 , DBA 只 需 设 置 合理 的 UNDO_RETENTION 参数 , 然后 创建 充足 的 UNDO 表 
空间 , 剩 下 的 事情 都 可 以 交 给 Oracle 自己 去 完成 。 很 多 2000 年 后 入行 的 DBA 都 没有 经 历 过 手工 
管理 UNDO 的 痛苦 ， 这 是 十 分 幸福 的 ， 不 过 也 正 是 因为 我 们 很 少 关 注 UNDO， 才 导致 了 现在 很 
多 ОВА 对 UNDO 的 机 制 和 原理 一 知 半 解 ， 一 且 碰 到 问题 ， 就 十 分 麻烦 了 。 

在 本 节 中 ， 老 白 会 带 着 大 家 简单 了 解 UNDO 的 基本 概念 ， 并 重 温 UNDO 手工 管理 时 代 的 一 
些 主 要 优化 思路 。 即 使 不 需要 手工 管理 UNDO, 了 解 一 些 这 方面 的 知识 也 更 有 助 于 今后 分 析 有 关 
UNDO 的 问题 。 


6.1 UNDO 的 基本 原理 


UNDO 是 事务 层面 的 组 件 , 它 实现 了 数据 库 的 事务 回 滚 和 一 致 性 读 。 从 9i 版 本 开始 ,UNDO 
还 为 闪 回 查询 提供 了 保证 。 正 因为 UNDO 和 应 用 的 关系 十 分 密切 , 所 以 我 们 需要 深入 了 解 UNDO 
的 基本 原理 和 算法 ， 以 便于 解决 维护 工作 中 可 能 出 现 的 问题 。 
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6.1.1 UNDO 表 空 间 和 回 滚 段 


UNDO 表 空 间 是 一 个 十 分 特殊 的 表 空 间 ， 它 不 存储 表 和 索引 数据 ， 而 只 存放 回 滚 段 
(ROLLBACK SEGMENT )。 回 滚 段 是 一 种 非常 有 趣 的 机 制 Oracle 回 滚 段 的 作用 不 仅仅 局 限于 
事务 的 回 滚 , 一 致 性 读 是 回 滚 段 的 第 二 个 作用 。 通 过 一 致 性 读 衍生 出 来 的 内 回 查 询 只 能 算是 一 臻 
性 读 的 副产品 了 。 

在 % 版 本 之 前 ，UNDO 是 需要 DBA 手工 管理 的 。 在 创建 数据 库 时 会 默认 创建 一 个 RBS 表 
空间 ， 在 RBS 表 空 间 中 会 创建 几 个 回 深 段 。 一 般 来 说 ，DBA 还 需要 手工 调整 RBS 的 参数 ， 同 
时 新 创建 几 个 回 滚 段 ， 以 适应 系统 负载 的 需要 。 创 建 多 少 个 回 滚 段 ， 每 个 回 滚 段 的 初始 大 小 是 
多 少 ， 最 佳 大 小 是 多 少 ， 这 些 都 需要 DBA 自己 去 分 析 和 考虑 。 创 建 完 回 滚 段 后 ，DBA 还 要 手 
工 将 这 些 回 滚 段 写 和 参数 ROLLBACK_SEGMENTS 中 , 否则 数据 库 系 统 将 不 会 自动 使 用 这 些 回 
滚 段 。 

设计 回 滚 段 对 于 DBA 来 说 是 个 考验 ， 如 果 回 滚 段 配置 得 不 合理 ， 可 能 会 导致 性 能 问题 ， 从 

影响 系统 的 稳定 运行 。 很 多 DBA 在 这 方面 缺乏 经 验 , 因此 就 会 导致 那个 十 分 著名 的 ORA-1555 
错误 频 发 。 在 8i. 8.0 或 者 7.3 版 本 的 时 代 ， 面 试 官 最 喜欢 问 DBA 的 问题 就 是 “ORA-1555 是 怎 
么 发 生 的 ,如何 进行 优化 ”。 能 把 这 个 问题 回答 得 十 分 完美 的 DBA 水 平 确实 很 不 错 了 。 要 想 在 手 
工 管理 模式 下 尽 可 能 避免 ORA-1555 错误 ,需要 有 足够 大 的 RBS 空间 、 足 够 多 的 回 滚 段 ， 每 个 
回 滚 段 有 足够 大 的 OPTIMAL SIZE。 即 使 上 述 条 件 都 满足 ， 还 是 很 难 避 免 ORA-1555 的 出 现 ， 
为 有 些 查询 的 执行 时 间 太 长 ,SQL 质量 之 差 几 近 变 态 。 但 现在 ,如 果 有 一 个 面试 官 问 前 来 应 聘 的 
DBA， 如 何在 手工 管理 模式 下 尽 可 能 避免 ORA-1555 错误 ? 我 想 能 够 正确 回答 出 来 的 人 不 会 很 
多 。 因 为 进入 %i 版 本 以 后 ， 手 工 管理 回 滚 段 已 经 变 为 历史 。 在 UNDO MANAGEMENT-AUTO 
的 模式 下 ，UNDO 管理 已 经 相当 简单 了 ， 只 要 确保 有 一 个 足够 大 的 UNDO 表 空 间 ， 设 置 足够 大 
的 UNDO_RETENTION， 剩 下 的 一 切 就 可 以 交 给 Oracle 自己 去 完成 了 。UNDO 中 需要 配置 多 少 
AMERRE, A RBS 的 OPTIMAL SIZE 多 大 ， 这 些 都 是 RDBMS 根据 并 发 的 事务 数量 自动 判断 
的 。 从 10g 版 本 开始 ， 甚 至 连 UNDO RETENTION 也 自动 管理 了 ，Oracle 会 根据 UNDO 表 空 间 
的 大 小 和 MAXQUERYLENGTH 这 些 指标 ,自动 调整 UNDO. RETENTION 的 值 ， 从 而 充分 利用 
UNDO KZH, 保留 最 多 的 前 映像 。 因 此 很 多 DBA 会 发 现 ，10g 版 本 的 UNDO 表 空间 经 常 出 现 
100% 被 使 用 的 情况 ， 实际 上 这 是 十 分 正常 的 。 在 10g 版 本 中 ， 如 果 使 用 默认 的 
UNDO_RETENTION 自动 管理 , 那么 最 好 将 UNDO 表 空 间 的 所 有 文件 的 自动 扩展 属性 全 部 关闭 ， 
否则 经 过 一 段 时 间 的 运行 ， 你 会 发 现 UNDO 表 空 间 变 得 非常 大 。 

回 滚 段 用 于 存放 数据 修改 之 前 的 值 (包括 数据 修改 之 前 的 位 置 和 值 )， 称 为 前 映 象 。 回 滚 段 
的 头 部 包含 正在 使 用 的 该 回 滚 段 事务 的 信息 ， 一 个 事务 只 能 使 用 一 个 回 滚 段 来 存放 它 的 回 滚 信 
息 ， 而 一 个 回 滚 段 可 以 存放 多 个 事务 的 回 滚 信息 。 回 滚 段 的 主要 用 途 如 下 。 

о 事务 回 滚 。 当 事务 修改 表 中 数据 的 时 候 ， 该 数据 修改 前 的 值 ( 即 前 映像 ) 会 存放 在 回 滚 

段 中 。 当 用 户 回 滚 事务 (ROLLBACK ) Pf, Oracle 将 会 利用 回 滚 段 中 的 数据 前 映像 来 将 
已 修改 的 数据 恢复 到 原来 的 值 。 
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Па 事务 恢复 。 当 事务 正在 处 理 的 时 候 ， 例 程 失败 ， 回 滚 段 的 信息 保存 在 REDO 日 志文 件 中 ， 
Oracle 将 在 下 次 启动 数据 库 时 利用 回 滚 来 恢复 未 提交 的 数据 。 
о 读 一 致 性 。 当 一 个 会 话 正 在 修改 数据 时 ， 其 他 的 会 话 看 不 到 该 会 话 未 提交 的 修改 。 而 且 ， 
当 一 个 语句 正在 执行 时 , 该 语句 将 看 不 到 开始 执行 后 的 未 提交 的 修改 ( 语句 级 读 一 致 性 )。 
当 Oracle 执行 SELECT 语句 时 ，Oracle 依照 当前 的 系统 改变 号 ( SYSTEM CHANGE 
NUMBER，SCN ) 来 保证 任何 在 当前 SCN 之 前 的 未 提交 的 改变 不 被 该 语句 处 理 。 不 难 想 
象 ， 当 一 个 长 时 间 的 查询 正在 执行 时 ， 者 其 他 会 话 改 变 了 该 操作 要 查询 的 某 个 数据 块 ， 
Oracle 将 利用 回 滚 段 的 数据 前 映像 来 构造 一 个 读 一 致 性 视图 。 
a 闪 回 查询 。 从 9i 版 本 开始 ，Oracle 支持 闪 回 查询 ， 就 是 通过 UNDO 中 的 数据 ， 查 询 某 个 
SCN 之 前 的 数据 ， 或 者 查询 某 两 个 时 间 点 (或 者 SCN) 之 间 ， 某 张 表 发 生 了 哪些 变化 。 

每 个 回 滚 段 都 包含 一 些 扩展 (EXTENTS )。 回 滚 段 采用 一 种 循环 机 制 来 使 用 这 些 扩展 ， 当 某 
个 扩展 写 满 后 , 自动 切换 到 另外 一 个 扩展 继续 使 用 。 一 个 事务 会 将 回 滚 记录 写 在 回 滚 段 的 当前 位 
置 ， 并 且 通 过 记录 大 小 来 标明 记录 的 位 置 。 当 前 写 指针 是 回 滚 段 段 头 中 的 一 个 控制 结构 。 尾 部 
(TAIL ) 指 的 是 回 滚 段 中 最 后 一 条 记录 的 开始 位 置 。 

回 滚 段 的 数量 和 每 个 回 滚 段 的 大 小 对 于 回 滚 段 的 配置 来 说 至 关 重 要 。 在 OLTP 系统 中 , 应 设 
置 足 够 的 回 滚 段 数量 ， 以 避免 回 滚 段 冲 突 。 另 外 ,每 个 回 滚 段 的 大 小 也 应 该 足够 大 ， 以 便于 适应 
事务 处 理 的 需要 。Oracle 循环 使 用 回 滚 段 ， 所 有 的 在 线 回 滚 段 (除了 SYSTEM 回 滚 段 外 ) 都 会 
被 轮流 使 用 。Oracle 在 使 用 回 滚 段 的 时 候 ， 遵 循 以 下 原则 。 

а 一 个 事务 只 使 用 一 个 回 滚 段 来 记录 所 有 的 回 滚 记录 。 

口 多 个 事务 可 以 写 人 相同 的 扩展 。 

a 扩展 可 以 被 循环 使 用 ， 且 任何 一 个 扩展 都 不 会 被 跳 过 。 

а 如 果 不 能 使 用 下 一 个 扩展 ，Oracle 会 自动 分 配 一 个 新 扩展 ， 并 将 其 插入 到 这 个 环 中 。 

口 Oracle 不 会 使 用 被 尾部 占据 的 扩展 。 

从 上 述 原则 可 以 看 出 ， "q es noq Ps n 一 个 长 时 
间 事 务 哪 怕 只 使 用 了 一 个 字 节 ， 也 可 能 导致 该 扩展 不 能 被 马上 重用 ， 而 造成 回 滚 段 扩 展 。 

我 们 能 BECAS ARLE C 在 设置 回 滚 段 时 ,如 果 回 滚 段 足 够 大 , 那么 首先 需 
要 根据 实际 的 事务 大 小 来 确定 回 滚 段 的 存储 参数 , 使 回 滚 段 头 不 会 很 快 就 转 到 段 尾 ， 以 避免 回 滚 
段 快速 地 进行 扩展 。 第 二 个 应 该 注意 的 问题 是 ， 如 果 执 行 一 个 长 时 间 运 行 的 查询 ,这 个 查询 访问 
的 数据 变化 频率 十 分 快 ， 那 么 就 需要 足够 大 的 回 滨 段 ， 以 保证 查询 结束 之 前 不 会 出 现 ORA-1555 
错误 ( SNAPSHOT TOO OLD )。 

回 深 段 的 大 小 取决 于 数据 库 中 事务 的 特点 , 应 该 满足 数据 库 日 常事 务 的 要 求 , 而 不 是 针对 那 
些 不 经 常 使 用 的 大 事务 。 回 深 段 的 数量 设置 要 保证 不 会 发 生 回 深 段 竞争 。 可 以 通过 下 列 代码 来 查 
看 是 否 存 在 回 滚 段 竞争 。 

SELECT CLASS, COUNT FROM V$WAI TSTAT WHERE CLASS = ' %undo%'; 

任何 非 0 的 COUNT 值 都 说 明 存 在 回 滚 段 头 争 用 。 不 过 在 UNDO 自动 管理 的 时 代 ， 这 一 切 
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往往 不 太 需 要 DBA 去 操心 了 ,只 要 UNDO 表 空 间 足 够 大 ,UNDO_RETENTION 设置 得 合理 一 些 ， 
回 滚 段 的 争 用 就 不 会 对 系统 造成 多 大 的 影响 ，ORA-1555 这 个 世界 级 的 难题 也 就 迎刃而解 了 。 不 
过 如 果 SQL 编写 得 太 差 ， 那 么 再 大 的 UNDO. RETENTION 也 没 办 法 避免 ORA-1555， 这 时 只 能 
从 应 用 优化 的 角度 人 手 了 。 

事情 总 是 有 特例 的 ， 在 某 些 情况 下 ， 使 用 UNDO 自动 管理 ， 可 能 总 是 无 法 解决 UNDO “JH 
的 问题 ， 而 且 这 种 争 用 对 系统 总 体 性 能 影响 较 大 ， 那 么 我 们 就 必须 放弃 UNDO 自动 管理 ， 改 用 
UNDO 手工 管 理 了 。 尽 管 这 种 情况 很 少 出 现 ， 老 白 还 是 遇 到 过 的 ， 因 此 对 于 广大 DBA 来 说 , m 
IR UNDO 自动 管理 不 需要 你 们 辛苦 地 维护 UNDO 和 回 滚 , 但 是 了 解 一 些 UNDO 手工 管理 的 基本 
技术 还 是 很 有 必要 的 。 


6.1.2 ITL 和 UNDO 


ITL 就 是 我 们 常 说 的 事务 柳 ， 它 存在 于 数据 块 中 ,位 于 块头 的 44B 之 后 。 每 个 ITL 项 的 大 小 
都 是 固定 的 24B。 在 一 个 数据 块 被 格式 化 后 ， 首 先 会 默认 创建 数 个 ITL (不 同 的 版 本 略 有 不 同 ， 
比如 ，10g 版 本 的 数据 库 表 会 默认 创建 两 个 ITL )。 当 ITL 空间 不 够 用 时 ， 系 统 会 男 外 分 配 24B, 
扩展 一 个 新 的 ITL。 

ITL 对 于 事务 来 说 至 关 重 要 。 在 一 个 事务 要 修改 某 个 数据 块 中 的 某 条 记录 时 ， 首 先 要 找到 一 
个 空闲 的 ITL 槽 ， 然 后 将 该 ITL 覃 的 序号 登记 在 这 个 数据 行 的 头 部 。ITL 槽 的 结构 如 下 : 

struct ITL $2245 { 


kxid_ st #4 ; 
kuba_st 最 后 一 个 改动 的 UND0 地 址 (UBA) ; 
0072 锁 标 识 ， 在 锁定 时 记录 本 事务 在 本 块 中 锁定 的 记录 数 
ub2 SCN WRAP; 
ub4 SCN BASE; 
E: 
不 难看 出 ， 锁 标识 Cktbitflg ) 可 以 在 事务 锁定 时 记录 被 锁定 的 记录 数 ， 因 此 ， 同 一 个 事务 
如 果 在 一 个 数据 块 中 修改 了 多 条 记录 ， 只 需要 申请 一 个 ITL 槽 。 在 事务 提交 之 前 ， 这 个 ITL f 
是 被 锁定 的 ， 不 能 复 用 。 事 务 提 交 或 者 回 滚 后 ，ITL 槽 解除 锁定 ， 其 他 事务 可 以 再 次 使 用 这 个 
ITL ṣi. WRR PRAA ITL 槽 都 被 占用 了 ， 那 么 就 需要 新 扩展 一 个 TL 槽 供 这 个 事务 使 用 。 
这 时 如 果 不 凑 巧 ， 块 中 已 经 无 法 再 分 配 24B 来 扩充 ITL 槽 了 ， 那 么 这 个 事务 就 只 能 等 待 ITL。 
这 种 等 待 也 会 体现 在 TX 行 锁 等 待 , 不 过 这 种 行 锁 等 待 和 普通 的 行 锁 等 待 不 同 , 其 LMODE 是 4 
而 不 是 6。 

如 果 ITL 等 待 比较 严重 , 那 就 需要 加 大 INITRANS 参数 了 。 不 过 需要 注意 的 是 , 加 大 这 个 参 
数 后 ,新 格式 化 的 数据 块 会 使 用 新 参数 , 而 旧 的 数据 块 不 会 改变 , 除非 对 表 进 行 重组 ( 比如 MOVE 
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或 者 EXP/IMP )。 

除了 修改 数据 块 的 事务 外 ， 一致 性 读 也 依赖 于 ITL。 如 果 某 一 致 性 读 操 作 在 读 取 某 个 数据 块 
中 的 数据 时 ， 发 现 这 个 数据 太 新 了 ， 就 会 根据 这 条 数据 头 部 的 ITC 标识 找到 这 个 ITC 通过 ITL 
的 UBA， 并 找到 其 修改 前 的 前 映像 数据 ， 从 而 读 取 到 较 早 的 数据 。 
通过 上 述 内 容 ， 可 能 有 些 朋 友 的 疑问 已 经 得 到 了 解答 ， 我 们 也 理解 了 一 致 性 读 是 如 何 通 过 
ITL 找到 前 映像 的 。 不 过 有 些 细心 的 朋友 可 能 会 思考 , 这 样 似乎 还 不 足够 , 因为 事务 提交 后 , ITL 
可 以 被 重用 , 那么 以 前 的 ITL 信息 可 能 会 被 覆盖 , 我们 找到 的 数据 就 可 能 不 是 预期 的 。 其 实 不 用 
担心 这 个 问题 ， 在 ITL 被 覆盖 前 ， 其 信息 会 被 复制 到 UNDO 记录 中 ， 只 要 通过 UNDO 记录 中 原 
来 的 UBA 信息 ， 就 可 以 找到 正确 的 信息 了 。 


6.1.3 如何 转 储 UNDO 


从 Oracle 7.3 开始 ,我 们 就 可 以 转 储 UNDO 的 信息 了 。 在 日 常 维护 工作 中 ， 转 储 UNDO 信 
息 的 机 会 比较 少 。 不 过 在 一 些 故障 分 析 或 者 性 能 分 析 中 ， 有 时 还 是 会 用 到 这 项 技术 。 这 里 将 简单 
介绍 如 何 转 储 UNDO 信息 。 转 储 UNDO 信息 需要 使 用 sysdba 或 者 ѕуѕорег 账号 ,然后 通过 ALTER 
SYSTEM DUMP UNDO 命令 来 完成 。 其 语法 如 下 所 示 : 

ALTER SYSTEM DUMP UNDO[ HEADER «rbs-name» ][ BLOCK «rbs-name» [ «filter» ] ]; 


Filters: 

XI D «usn» «slot» <sqn> 11/ 通过 Select XI DUSN, XI DSLOT, XI DSQN from v$transaction 
[1 可 以 获取 上 述 信息 

UBA MIN «file» «block» 

UBA MAX «file» «block» 

EXTENT MIN <extentno> 

EXTENT MAX «extentno»0BJ NO «obj no» 

LAYER «layer» 

LEVEL «level» 


下 面 举例 说 明 。 
(1) Feta FR Bk 
(2) SQL> alter system dump undo header ' SYSSMUOIS'; 
(3) 根据 XID 来 转 储 UNDO 链 。 
a. 找到 XID。 


SQL» select xidusn, xidslot, xidsqn from v$transaction; 
XI DUSN XI DSLOT XI DSQN 


b. 根据 上 一 步 结 果 中 的 XIDUSN 找到 回 滚 段 。 


SQL» select name from v$rollname where usn=3; 
NAME 


_SYSSMU3$ 
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c. 转 储 UNDO 链 。 
SQL» alter system dump undo block ' SYSSMU3$' xid 3 3 834 


6.1.4 UNDO 自动 管理 是 如 何 工作 的 


在 前 面 已 经 提 到 , UNDO 自动 管理 可 以 将 DBA 从 头疼 的 UNDO 管理 工作 中 解放 出 来 。 不 过 
在 某 些 情 况 下， 我 们 可 能 需要 调整 UNDO 自动 管理 的 相关 配置 ， 甚 至 回 过 头 来 使 用 UNDO 手工 
管理 。 因 此 通过 本 节 的 内 容 去 了 解 UNDO 自动 管理 中 的 一 些 基本 原理 还 是 十 分 必要 的 。 

UNDO 的 自动 管理 基于 几 个 要 素 。 首 先 , 在 UNDO 自动 管理 模式 下 , 一 个 数据 库 实例 只 能 
一 个 独立 的 UNDO 表 空 间 , 该 实例 中 除 SYSTEM 以 外 的 所 有 回 滚 段 都 会 被 创建 在 这 个 表 空 间 中 。 

其 次 ， 回 滚 段 是 根据 系统 的 负载 情况 动态 创建 的 ， 处 于 不 同 的 状态 ( ONLINE/OFFLINE )。 
SMON 根据 平均 每 秒 的 事务 数 来 确定 系统 中 所 需要 的 回 滚 段 数量 。 每 秒 处 理 的 事务 数量 越 高 ,处 
TERREN (ONLINE) 回 滚 段 也 就 越 多 。 如 果 业 务 高 峰 过 去 了 ， 回 滚 段 的 需求 量 也 会 下 降 。 
这 时 如 果 有 些 回 滚 段 的 事务 都 已 经 提交 了 ， 而 且 所 有 的 数据 都 已 经 不 在 UNDO RETENTION (я: 
护 范围 内 ， 那 么 这 些 回 滚 段 就 会 处 于 离线 状态 (OFFLINE )。 

在 UNDO 自动 管理 的 模式 下 ，SMON 也 会 根据 回 滚 段 的 使 用 情况 ， 自 动 计算 理想 数量 ， 确 
保 在 线 的 回 深 段 不 会 出 现 拌 动 现象 。 

如 果 我 们 使 用 10g 版 本 的 数据 库 ， 那 么 UNDO AUTOTUNE 参数 默认 为 TRUE。 这 种 情况 
下 ,SMON 会 根据 MAXQUERYLENGTH 和 UNDO 表 空 间 的 大 小 自动 调整 UNDO_RETENTION 
的 值 ， 尽 量 使 最 长 的 查询 不 出 现 ORA-1555 错误 。 这 种 管理 模式 会 尽 可 能 地 使 用 UNDO REH, 
从 而 确保 MAXQUERYLENGTH。 

Oracle 10g 如 何 实现 UNDO_RETENTION 的 自动 调整 呢 ?7 如 果 将 UNDO MANAGEMENT 
设置 为 AUTO， 那 么 无 论 UNDO RETENTION 是 否 被 设置 ，MMON 都 会 以 30 秒 为 周期 ， 计 算 
MAX QUERY LENGTH, 并 将 TUNED_UNDORETENTION 参数 设置 为 “MAXQUERYLENGTH 
+ < 修正 值 >”。 这 一 点 可 以 通过 下 面 的 查询 来 验证 。 


SQL> select tuned undoretention, maxquerylen, maxqueryid from všundostat 


TUNED UNDORETENTI ON MAXQUERYLEN MAXQUERYID 
66438 65534 dc78zsn04tj4u 
65829 64925 dc78zsn04tj4u 
65221 64316 dc78zsn04tj4u 
64673 64012  dc78zsn04tj 4и 
64064 63404  dc78zsn04tj 4и 
63456 62795  dc78zsn04tj 4u 
62848 62187 dc78zsn04tj 4u 
62239 61578  dc78zsn04tj 4u 
61630 60969  dc78zsn04tj 4и 
61022 60361 dc78zsn04tj 4и 
60474 59753 dc78zsn04tj 4и 


某 些 文档 中 提 到 的 修正 参数 是 300, 但 老 白 在 不 同系 统 中 观察 到 的 情况 略 有 不 同 。 不 过 这 一 点 
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已 经 不 重要 了 ,我 们 需要 知道 的 是 MAX QUERY LENGTH Xf UNDO RETENTION 管理 产生 的 影响 。 


6.1.5 系统 回 滚 段 的 作用 


使 用 CREATE DATABASE 命令 创建 数据 库 ， 仅 仅 会 创建 一 个 回 滚 段 一 一 系统 回 滚 段 ， 这 个 
回 滚 段 会 被 创建 在 SYSTEM 表 空 间 中 。 系 统 回 滚 段 和 其 他 回 滚 段 (包括 其 他 创建 在 系统 表 空 间 


中 的 回 深 段 ) 存在 本 质 的 不 同 ,， 系统 回 滚 段 只 能 用 于 对 系统 表 空 间 的 对 象 进行 操作 的 事务 。 设 置 


系统 回 滚 段 是 为 了 给 Oracle 的 一 些 内 部 事务 提供 回 滚 空间 ， 包 括 一 些 Oracle 空间 管理 操作 和 一 
些 对 系统 的 数据 字典 表 进 行 的 操作 。 


下 列 代码 可 以 验证 系统 回 滚 段 的 使 用 范围 。 


- - 首先 创建 两 张 表 , test] 存放 于 系统 表 空 间 ，t est 2 存放 于 用 户 表 空间 。 


SQL» create table testl (a integer ) tablespace system 


Table 


created. 


SQL» create table test2 (a integer) tablespace users 


Table 


created. 


-- 确认 只 有 系统 RB9 是 在 线 的 。 


SQL» select segment name ,Status from dba rollback segs 


SEGMENT NAME STATUS 
SYSTE ONLI NE 
_SYSSMU1$ OFFLINE 
_SYSSMU2$ OFFLINE 
_SYSSMU3$ OFFLINE 
_SYSSMU4$ OFFLINE 
_SYSSMU5$ OFFLINE 
_SYSSMU6$ OFFLINE 
_SYSSMU7$ OFFLINE 
_SYSSMU8$ OFFLINE 
_SYSSMU9$ OFFLINE 
_SYSSMU10$ OFFLINE 
SQL> insert into testl values (1); 
1 row created. 
SQL> commit; 
SQL> insert into test2 values (2); 
insert into test2 values (2) 

* 
ERROR at line 1: 


ORA- 01552: cannot use system rollback segment for non-system tablespace 'USERS 

从 上 面 的 ORA-1552 报错 可 以 看 出 , 非 系 统 表 空间 的 对 象 不 能 使 用 系统 RBS。 这 样 设置 的 缺 
点 是 ,系统 回 滚 段 不 能 保证 只 被 数据 字典 表 使 用 。 如 果 一 张 用 户 表 被 创建 在 系统 表 空 间 , 那么 该 
表 的 操作 也 可 以 使 用 系统 表 空 间 。 因 此 不 允许 把 用 户 表 创建 在 系统 表 空 间 是 一 条 铁 律 。 

其 他 位 于 系统 表 空 间 的 回 深 段 没有 这 种 限制 , 但 是 仍然 不 建议 在 系统 表 空 间 中 存放 其 他 回 滚 
段 ， 以 避免 引起 性 能 问题 。 
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6.1.6 著名 的 ORA-1555 


如 果 我 们 要 进行 大 查询 (一 般 把 执行 时 间 比 较 长 、 开 销 比较 大 的 查询 称 为 大 查询 )， 比 如 进 
行 一 个 大 的 统计 分 析 ， 那 么 可 能 会 出 现 ORA-1555 错误 (SNAPSHOT TOO OLD )。 从 Oracle 的 
错误 信息 来 看 , 这 个 错误 是 回 深 段 太 小 导致 的 , 其 实 这 是 一 种 误导 。 无 论 怎样 设置 回 深 段 的 大 小 ， 
都 有 可 能 发 生 这 个 问题 ， 加 大 回 深 段 的 大 小 并 不 能 解决 这 个 问题 。 

一 个 事务 启动 时 ，Oracle 会 保存 它 启动 时 的 SCN。 当 该 事务 执行 的 时 候 ，Oracle 会 检查 所 有 
的 行 ， 确 认 这 些 数据 从 事务 启动 的 时 间 点 开始 就 没有 发 生变 化 。 如 果 要 访问 的 数据 发 生 了 变化 ， 
那么 Oracle 会 到 回 滚 段 中 去 查找 那个 时 间 点 的 数据 (通过 比较 SCN 可 以 找到 这 个 数据 )。 对 于 没 
有 提交 的 事务 ， 数 据 会 一 直 在 回 滚 段 中 存在 ， 这 些 数据 不 会 产生 ORA-1555 问题 。 而 对 于 那些 已 
经 提交 的 事务 , 回 深 段 可 能 会 被 其 他 事务 覆盖 或 者 在 使 用 OPTIMAL 模式 时 被 Oracle jt. 碰 到 
这 种 情况 ,就 会 出 现 ORA-1555 错误 。 无 论 系 统 拥有 多 大 的 回 滚 段 ， 提 交 过 的 事务 相关 的 回 滚 段 
空间 都 有 可 能 被 覆盖 。 回 滚 段 越 大 ， 被 覆盖 的 机 会 越 小 , 所 以 错误 信息 才 会 提示 回 滚 段 太 小 。 但 
是 机 会 小 不 等 于 不 发 生 ， 因 此 简单 地 扩大 回 滚 段 并 不 是 解决 ORA-1555 问题 的 有 效 方法 。 

解决 ORA-1555 问题 最 简单 的 方法 是 调整 那些 较 大 事务 的 执行 时 间 , 使 之 能 够 在 其 他 事务 较 
小 时 执行 , 或 者 把 大 事务 分 解 为 一 些小 事务 。 但 事实 上 最 简单 的 解决 方法 往往 也 是 最 不 可 能 实现 
的 方法 , 很 多 应 用 系统 无 法 完全 按照 DBA 的 意志 去 执行 。 因此 , 要 从 技术 角度 去 解决 ORA-1555 
问题 ， 这 需要 从 以 下 几 个 方面 入 手 。 

首先 ， 确 保 所 有 可 用 的 回 滚 段 都 是 在 线 的 。 回 滚 段 越 多 ， 回 滚 信息 被 覆盖 的 机 会 就 越 少 。 

其 次 ,确保 所 有 回 滚 段 的 扩展 属性 都 是 相同 大 小 的 。 因 为 最 容易 导致 ORA-1555 错误 的 回 滚 
段 是 那些 较 小 的 、 很 容易 发 生 回转 的 回 滚 段 。 

从 Oracle 9i 开始 ， 设 置 UNDO RETENTION 参数 可 以 解决 大 部 分 ORA-1555 问题 。 
UNDO RETENTION 参数 的 含义 是 UNDO 信息 在 UNDO 表 空 间 中 保留 的 时 间 , 单位 是 秒 。 要 注 
意 的 是 ， 在 RAC 环境 下 使 用 该 参数 ， 所 有 的 实例 都 要 设置 相同 的 值 ， 否 则 会 导致 数据 库 故 障 。 
设置 较 大 的 UNDO_RETENTION 参数 时 ,要 注意 UNDO 表 空 间 需 要 有 足够 的 空间 来 保留 旧 数 据 。 
另外 ,UNDO_RETENTION 并 不 是 任何 时 候 都 能 得 到 保证 的 ,也 就 是 说 ,并 不 能 保证 所 有 的 UNDO 
数据 都 不 会 在 UNDO_RETENTION 保护 的 时 间 内 被 履 盖 ,如 果 UNDO 表 空 间 的 容量 不 足以 支撑 
UNDO RETENTION, 那么 在 UNDO. RETENTION 保护 范围 内 的 UNDO 数据 也 有 可 能 被 覆盖 。 
从 Oracle 10g 开始 提供 了 “保证 ”模式 ， 确 保 UNDO 记录 在 UNDO_RETENTION 保护 范围 内 不 
会 被 覆盖 。 在 “保证 ”模式 下 ， 如 果 UNDO 表 空 间 不 足以 支撑 UNDO_RETENTION 的 需要 ， 系 
统 会 出 现 UNDO 表 空 间 不 足 的 错误 ,因此 要 使 用 “保证 ”模式 ,就 必须 确保 UNDO 表 空 间 充 足 。 
虽然 Oracle 9i 提供 了 一 些 手 段 来 解决 ORA-1555 问题 , 但 对 于 已 设计 完成 的 应 用 系统 , 优化 
应 用 才 是 最 重要 的 。 如 果 某 个 操作 在 以 前 是 可 以 完成 的 ， 而 现在 出 现 了 ORA-1555 错误 ,那么 不 
要 急于 调整 UNDO RETENTION 参数 ， 而 要 尽量 找 出 原因 所 在 ， 是 因为 数据 量 的 变化 导致 执行 
时 间 变 长 , 还 是 因为 优化 器 选择 了 非 最 优 的 执行 计划 …… 找 到 真正 的 故障 并 排除 它 才 是 最 好 的 解 
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6.1.7 ” 回 滚 段 手工 管理 


一 般 情 况 下 ， 现 在 我 们 很 少 会 采用 UNDO 的 手工 管理 ,不 过 在 一 些 极端 的 应 用 场合 ， 比 如 ， 
UNDO 自动 管理 碰 到 一 些 可 能 导致 严重 后 果 的 Bug, 或 者 应 用 的 极端 性 导致 自动 管理 无 法 正常 工 
作 ， 这 时 就 只 能 手工 管理 回 滚 段 了 。 

在 一 个 事务 的 大 小 和 并 发 性 波动 都 不 大 的 系统 中 , 配置 回 滚 段 表 空 间 十 分 容易 。 通 过 前 面 几 
节 介 绍 的 方法 ,可 以 很 容易 地 计算 出 系统 中 大 致 需要 多 少 个 回 滚 段 , 以 及 每 个 回 滚 段 的 最 佳 大 小 。 
创建 一 个 表 空 间 ， 使 其 空间 不 小 于 所 有 回 滚 段 最 佳 大 小 总 和 的 120% (如 果 存 储 空间 足够 ， 建 议 
不 小 于 所 有 回 滚 段 最 佳 大 小 的 150%, 其 至 更 多 )。 如 果 会 出 现 比较 大 的 事务 ,可 以 适当 调 高 这 个 
比例 。 创 建 回 滚 段 的 时 候 , 使 用 OPTIMAL 参数 , 并 且 设 置 所 有 的 回 滚 段 都 具有 相同 的 扩展 参数 。 

经 常 出 现 大 型 事务 操作 的 系统 是 最 难 管理 的 系统 , 有 两 种 方案 可 以 选择 , 一 种 是 创建 较 少 的 
回 滚 段 ， 每 个 回 滚 段 的 大 小 都 比较 大 ， 能 够 适合 大 型 事务 。 另 一 种 方案 是 对 于 大 型 的 事务 处 理 ， 
使 用 独立 的 大 型 回 滚 段 。 由 于 第 一 种 方法 减少 了 回 滚 段 的 数量 , 因此 可 能 会 导致 回 滚 段 段 头 的 冲 
突 。 第 二 种 方法 需要 应 用 程序 使 用 SET TRANSACTION USE ROLLBACK SEGMENT 命令 来 指 
定 回 滚 段 (需要 注意 的 是 ,对 于 DDL 操作 ， 这 条 语句 无 效 )， 并 且 需 要 对 应 用 系统 进行 修改 。 在 
应 用 程序 层面 就 很 好 地 划分 回 滚 段 的 使 用 虽然 会 加 大 开发 的 难度 , 但 是 系统 往往 可 以 获得 最 佳 的 
性 能 。 在 这 种 情况 下 ，OPTIMAL 参数 就 不 适合 使 用 了 。 

对 于 存在 少量 大 事务 的 系统 ， 比 如 ,一 个 偶尔 进行 统计 操作 的 OLTP 系统 ， 在 这 种 环境 下 使 
用 OPTIMAL 参数 ， 并 设置 每 个 回 滚 段 的 OPTIMAL 值 是 最 小 的 回 滚 段 覆盖 值 ， 同 时 保证 回 滚 段 
所 在 的 表 空 间 能 够 满足 大 型 事务 扩展 回 滚 段 的 需求 。 在 这 样 的 配置 下 , 某 些 回 滚 段 会 偶尔 扩展 到 
很 大 , 但 是 很 快 这 些 回 滚 段 又 会 恢复 正常 。 这 样 会 产生 一 些 回 滚 段 申 请 和 释放 带 来 的 开销 ， 导 致 
性 能 略微 下 降 。 因 此 在 这 种 情况 下 ， 选 择 合适 的 OPTIMAL 大 小 十 分 关键 。 

在 创建 回 滚 段 的 语句 中 ,可 以 使 用 OPTIMAL 选项 。 使 用 该 选项 后 ， 系 统 会 通过 自动 管理 来 
实现 最 佳 的 回 滚 段 大 小 ， 从 而 使 系统 中 回 滚 段 的 浪费 和 扩展 最 小 化 。 使 用 OPTIMAL 选项 后 , 在 
事务 提交 后 ， 如 果 不 再 使 用 回 滚 段 的 数据 ， 超 过 OPTIMAL 指定 值 的 部 分 回 滚 段 会 被 自动 缩小 。 

当 一 个 导致 回 滚 段 扩展 的 事务 完成 后 , 在 回 滚 段 头 移动 到 下 一 个 数据 块 时 ,系统 会 计算 段 的 
大 小 。 如 果 超 过 了 最 优 值 , 那么 数据 库 会 考虑 释放 一 些 扩展 。 如 果 在 两 个 连续 的 扩展 中 都 没有 活 
跃 的 事务 ,就 会 释放 其 中 一 个 扩展 。 需要 保持 两 个 连续 的 空 扩展 的 唯一 理由 是 ， 当 前 的 事务 可 能 
需要 使 用 其 中 的 一 个 扩展 。( 如 果 空 扩展 被 释放 了 ， 而 下 一 个 扩展 正好 又 是 满 的 ， 那么 只 能 重新 
分 配 一 个 扩展 。) 如 果 需 要 的 话 ， 在 一 个 事务 中 ， 可 以 释放 多 个 扩展 。 由 于 回 滚 段 采用 的 是 循环 
使 用 机 制 ， 以 这 种 方式 释放 的 扩展 所 包含 的 数据 是 最 旧 的 。 

OPTIMAL 语句 是 一 种 十 分 有 效 的 工具 ， 在 使 用 OPTIMAL 时 需要 注意 一 些 问 题 。 首 先 ， 分 
配 和 释放 扩展 会 带 来 较 大 的 开销 ， 如 果 OPTIMAL 设置 得 不 合理 ， 就 会 带 来 性 能 问题 ， 特 别 是 在 
OPTIMAL 过 小 时 。 在 设置 回 滚 段 的 大 小 时 ， 最 好 的 方法 是 设置 所 有 回 滚 段 的 大 小 都 能 适合 单个 
事务 的 大 小 ,这 看 起 来 简单 ,但 实施 起 来 难度 却 很 大 ， 比 如 ,系统 最 大 的 事务 是 GB, ， 而 系统 中 
有 几 十 个 回 滚 段 ， 要 把 每 个 回 滚 段 都 设置 为 2GB 是 很 难 实现 的 。 因 此 ， 回 滚 段 的 最 优 设置 应 该 
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能 够 适合 90% 左 右 的 事务 。 

另外 要 注意 的 是 , 在 事务 结束 时 ,不 会 马上 回收 回 滚 段 。 只 有 当 另 外 一 个 事务 转移 到 下 一 个 
扩展 ， 发 现 需要 回收 空间 时 ， 才 会 进行 回收 。 

最 后 一 点 老 白 想 要 说 的 是 ,在 UNDO 手工 管理 的 时 代 ， 存 储 空间 是 十 分 昂贵 的 ，DBA 往往 
无 法 获得 足够 的 UNDO 空间 。 因 此 我 们 在 计算 回 滚 段 数量 和 OPTIMAL SIZE 的 时 候 往往 会 斤 斤 
计较 。 在 存储 空间 价格 已 经 降低 到 每 TB 容量 1 万 元 左右 的 时 候 ， 大 多 数 情况 下 我 们 没 必要 故意 
为 难 自己 。 设 置 较 大 的 UNDO 表 空 间 总 是 不 会 有 错 的 ， 一 些 那个 时 代 的 UNDO 管理 技巧 也 到 了 
要 抛弃 的 时 候 了 。 


6.2 ”如 何 分 析 和 优化 UNDO 


UNDO 优化 在 自动 管理 和 手工 管理 模式 下 是 截然 不 同 的 。 在 UNDO 手工 管理 模式 下 , UNDO 
优化 具有 一 定 的 难度 。 首 先 ， 我 们 需要 根据 系统 的 并 发 度 ， 考 虑 回 滚 段 RBS) 的 数量 ， 创 建 足 
够 的 RBS 是 确保 UNDO 效率 的 重要 因素 。 接 下 来 ,我 们 需要 考虑 的 问题 是 每 个 RBS 的 OPTIMAL 
SIZE， 也 就 是 最 佳 RBS 大 小 。 在 RBS 扩展 到 大 于 OPTIMAL SIZE 的 情况 下 ， 当 RBS 不 再 需要 
那么 大 的 空间 时 , 就 会 逐渐 释放 , 直到 收缩 至 OPTIMAL SIZE 指定 的 大 小 ,设置 合理 的 OPTIMAL 
SIZE 可 以 避免 RBS 不 停 地 扩展 和 收缩 ， 从 而 保证 RBS 的 性 能 。 

总 体 来 说 , 在 手工 管理 回 滚 段 的 时 代 ， 如 果 碰 到 了 回 滚 段 导 致 的 性 能 问题 ,那么 处 理 起 来 还 
是 十 分 棘手 的 ，DBA 必须 对 回 滚 段 有 深刻 的 认识 才能 够 驾驭 其 优化 工作 。 幸 运 的 是 ， 现 在 我 们 
很 少 会 遇 到 这 样 的 问题 了 , 在 UNDO 自动 管理 的 情况 下 ， 回 滚 段 出 现 性 能 问题 的 机 率 十 分 小 。 
我 们 可 以 通过 US-Undo Segment 锁 等 待 所 占 的 比例 来 判断 UNDO 是 否 存 在 严重 的 性 能 问题 。 这 
个 锁 等 待 如 果 排 在 等 待 事件 的 前 列 ， 就 说 明 UNDO 自动 管理 出 现 了 性 能 问题 。 一 般 情况 下 ， 我 
们 只 需 设 置 足够 大 小 的 UNDO 表 空 间 ， 其 他 的 事情 就 可 以 交 给 SMON 去 管理 了 。 在 AWR 报告 
中 ， 我 们 可 以 通过 UNDO 的 统计 信息 来 判断 其 健康 性 。 


Num Undo Number of Max Qry Max Tx Tun Ret STO/ uS/uR/ uU/ 


End Time Blocks Transactions Len (s) Concy (mins) 009 eS/eR/ eU 
26-Mar 10:01 42,139 42,710 44,800 29 2,627 0/0  1/0/0/12/359 
26-Mar 09:51 59,680 46,808 1,410 48 2,633 0/0  7/0/0/4/8576 
26-Mar 09:41 53, 822 46,611 2,841 25 2,640 0/0 0/0/0/0/0/0 
26-Mar 09:31 51,879 46,734 2,238 40 2,640 0/0 3/0/0/7/2969 
26-Mar 09:21 47,943 51,812 1,635 31 2,650 0/0 2/0/0/8/2252 
26-Mar 09:11 43,589 56,175 2,202 42 2,720 0/0 0/0/0/11/192 
26-Mar 09:01 42,703 53,051 1,599 30 2,800 0/0 0/0/0/12/168 
其 中 的 STO 是 指 SNAPSHOT TOO OLD, ， 也 就 是 著名 的 ORA-1555 错误 。 如 果 这 个 值 不 为 
零 ， 说 明 在 某 个 时 间 段 出 现 了 ORA-1555. OOS 是 指出 现 OUT OF SPACE 的 计数 ， 如 果 这 个 值 


ANE, WH UNDO 表 空 间 不 足 。Max Огу Len (s) 是 指 MAX QUERY LENGTH, 单位 是 秒 。Max 
TX Сопсу 是 指 最 大 并 发 事务 数 ，Tun Ret 是 指 自动 调整 的 RETENTION fH. uS/uR/uU/eS/eR/eU 
这 几 项 指标 对 于 分 析 UNDO 的 使 用 情况 也 是 十 分 有 价值 的 。 
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О us unexpired Stolen; 

О uR unexpired Released; 
Q uU unexpired reUsed; 
O eS expired Stolen; 

O eR expired Released; 
0 eU expired reUsed。 


如 果 uS, uR KI uU 的 值 经常 不 为 零 ， 那 么 说 明 UNDO 表 空 间 可 能 不 足 。UNDO SEGMENT 
在 某 个 时 间 点 上 无 法 扩展 ,只 能 强制 回收 还 没有 过 期 的 EXTENT ,来 确保 新 的 事务 能 够 正常 运行 。 
在 现在 的 10е, 118 环境 下 ， 只 要 UNDO 表 空 间 的 VO 性 能 能 够 得 到 保证 ,在 UNDO 表 空 间 


足够 大 的 情况 下 ， 一 般 来 说 ，UNDO 不 


会 出 现 影响 系统 性 能 的 重大 故障 。 如 果 出 现 了 UNDO S 


致 的 性 能 故障 ， 那 么 要 首先 观察 这 是 否 是 由 于 UNDO SEGMENT OFFLINE/ONLINE 十 分 频繁 所 
导致 的 。 如 果 是 这 样 ， 就 说 明 系 统 可 能 出 现 了 Bug， 我 们 可 以 到 MOS 上 查找 相关 的 信息 ,或 者 


干脆 开 个 SR。 但 如 果 是 由 于 大 量 并 发 


有 务 所 导致 的 ， 那 么 最 好 还 是 从 应 用 的 角度 去 分 析 ， 看 看 


为 什么 会 有 这 么 大 的 并 发 事务 ， 能 和 否 通过 优化 应 用 来 解决 。 而 在 最 为 极端 的 情况 下 ,我 们 就 只 能 
放弃 UNDO 自动 管理 ， 采 用 手工 管理 UNDO 的 方法 来 解决 这 个 问题 了 。 


理解 PGA、 临 时 表 空 间 和 
排序 


РСА 是 Process Global Area 或 者 Program Global Area 的 缩写 ， 指 服务 进程 的 私有 内 存 空间 。 
PGA 中 包含 服务 进程 的 全 局 变量 、 数 据 结 构 和 控制 信息 ， 比 如 服务 进程 执行 查询 时 的 游标 。 PGA 
包含 的 信息 如 下 所 示 。 
а ALA SQL 区 域 : 存储 服务 进程 执行 SQL 所 需要 的 私有 数据 和 控制 结构 ,包括 固定 区 域 和 

运行 时 区 域 ( Run-time Area ). 固定 区 域 的 数据 在 游标 关闭 前 一 直 存 在 , 运行 时 区 域 在 SQL 

执行 的 时 候 存 在 .Oracle 执 行 SQL 的 第 一 步 就 是 创建 运行 时 区 域 ,对 于 INSERT DELETE. 

UPDATE 语句 ， 执 行 结束 后 ， 该 区 域 就 被 释放 了 ; 而 对 于 SELECT 操作 ， 只 有 所 有 的 结 

果 集 都 被 读 取 完毕 或 者 查询 取消 了 ,该 区 域 才 会 被 释放 。 对 于 独立 服务 器 模式 的 连接 ， 

私有 SQL 区 域 在 PGA 中 分 配 空间 ;对 于 共享 服务 器 模式 的 连接 ， 私 有 SQL 区 域 在 SGA 


中 分 配 空 间 。 

о 会 话 空 间 : 用 于 存放 logon 信息 等 会 话 相关 的 控制 信息 。 对 于 共享 服务 器 模式 ， 会 话 空 间 
是 共享 的 。 

O SQL 工作 区 域 (SQL Work Area): 对 于 复杂 的 SQL， 比如 多 表 连 接 的 统计 查询 ,在 SQL 


执行 过 程 中 ， 如 果 有 下 列 操作 ， 则 会 使 用 一 些 额外 的 区 域 。 
m 排序 操作 ， 当 SQL 中 有 order by, group by. rollup 等 操作 的 时 候 ， 需 要 使 用 排序 空间 
来 处 理 。 
= 多 表 的 HASH 连接 ， 需 要 使 用 Hash Join Area 来 处 理 。 
= 位 图 连接 。 
创建 位 图 。 
PGA 使 用 的 空间 是 独立 于 SGA 的 。PGA 中 的 SQL 工作 区 域 对 于 系统 的 性 能 影响 很 大 ， 配 
置 合理 的 SQL 工作 区 域 参数 对 于 调整 系统 性 能 具有 十 分 重要 的 作用 。 
管理 PGA 也 是 DBA 一 项 十 分 重要 的 工作 ,设置 合理 的 PGA 可 以 减少 硬盘 排序 的 数量 ， 提 
高 大 型 表 连 接 和 统计 操作 的 性 能 。 要 想 了 解 PGA， 我 们 就 要 先 从 临时 表 空 间 和 临时 段 开 始 。 
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7.1 基本 概念 


尽管 РСА 比较 易于 理解 , 但 仍然 有 很 多 DBA 理解 得 不 够 透彻 。 因 为 PGA 的 构成 非常 复杂 ， 
不 像 SGA 中 的 组 件 那 么 清晰 明了 。PGA 包含 了 进程 中 私有 的 内 存 ， 这 些 内 存 的 功能 十 分 广泛 。 
本 节 将 介绍 РСА 的 基本 概念 ， 主 要 集中 在 PGA 和 SQL 执行 相关 的 内 容 ， 包 括 排序 区 、HASH 
工作 区 等 各 类 工作 区 。 

当然 ， 提 到 排序 ， 就 免不了 谈 到 临时 段 和 临时 表 空 间 ， 因 此 本 节 并 未 从 PGA 本 身 谈 起 ， 而 
是 先 从 临时 段 和 临时 表 空 间 开 始 。 


7.1.1 ”临时 表 空 间 和 临时 段 


临时 表 空 间 操作 和 排序 操作 是 数据 库 中 最 常见 的 操作 ， 也 是 令 绝 大 多 数 ОВА 最 为 困惑 的 操 
作 。 本 节 就 是 要 向 DBA 介绍 临 ps s 间 ， 以 及 在 临时 表 空 间 中 进行 的 主要 操作 。 

临时 表 空 间 用 于 存放 排序 、 临 时 表 等 数据 ， 其 信息 不 需要 REDO， 因 此 临时 表 的 DML 操作 
往往 比 普通 表 低 得 多 。 临时 段 不 | 在 于 临时 表 空 间 中 , 也 可 能 存在 于 普通 的 表 空间 里 。 比如， 
我 们 通过 CTAS 创建 一 张 表 ,在 CTAS 命令 没有 结束 前 ， 新 表 的 数据 是 放 在 临时 段 中 的 ， 这些 临 
时 段 在 CTAS 完成 的 时 候 会 被 转换 为 PERMENT Et. 

对 于 临时 表 空 间 的 管理 机 制 和 临时 段 的 算法 ，Oracle 7.3 是 一 个 革命 性 的 版 本 。 由 于 7.3 版 本 
推出 了 Oracle 第 一 个 集群 软件 OPS ， 而 原 有 的 临时 段 算 法 无 法 适应 OPS 的 需要 ， 因 此 Oracle X. 
推出 了 一 种 全 新 的 临时 段 管理 算法 。 在 7.3 版 本 之 前 ， 临 时 段 是 在 需要 时 分 配 ， 使 用 完毕 后 就 被 
删除 的 。Oracle 7.3 推出 的 新 算法 的 核心 就 是 SEP (SORT EXTENT POOL ), SEP 负责 管理 临时 
段 中 扩展 的 结构 ， 存 储 在 共享 池内 ， 任 何 需 要 使 用 排序 空间 的 操作 ， 都 需要 从 SEP 中 分 配 空闲 
的 扩展 ， 使 用 完毕 后 ， 不 需要 释放 该 空间 ， 只 需要 在 SEP 中 将 该 扩展 设置 为 空闲 。 

当 数据 库 实 例 启 动 后 , SMON 将 会 删除 该 实例 未 释放 的 临时 段 , 并 且 对 临时 表 空 间 进 行 碎片 
整理 。 在 这 个 操作 完成 前 ， 数 据 库 打 开 的 操作 不 能 完成 。 因 此 每 次 数据 库 重 启 后 ， 临 时 段 中 的 垃 
圾 都 会 被 完全 清理 。 当 数据 库 打 开 后 , 第 一 个 进行 的 硬盘 排序 操作 会 在 相关 的 临时 表 空 间 内 创建 
临时 段 ， 这 个 临时 段 也 是 整个 实例 唯一 的 临时 段 〈 在 新 的 临时 段 算法 下 ， 同 一 个 表 空 间 内 ， 每 个 
实例 只 有 一 个 临时 段 )。 临 时段 中 扩展 的 信息 会 被 记录 在 SEP 中 。 硬盘 排序 操作 会 在 SEP 中 查找 
可 用 的 扩展 ， 在 查找 前 ， 需 要 获得 SORT EXTENT POOL 门 锁 。 如 果 能 找到 可 用 的 扩展 ， 那 么 
SEP 中 已 被 分 配 的 扩展 就 会 被 标注 为 占用 状态 ; 如 果 找 不 到 可 用 的 扩展 , 那么 系统 就 会 试图 从 表 

空间 中 分 配 新 的 空间 , 而 如 果 这 个 分 配 工作 因为 表 空 s 间 的 空闲 空间 不 足 而 无 法 完成 , 那么 就 会 产 
生 一 个 ORA-1652 错误 。 

当 排 序 操作 完成 的 时 候 ,， 会 再 次 获取 SORT EXTENT POOL 门 锁 ， 并 且 将 使 用 的 扩展 标注 为 
空闲 ， 然 后 释放 SORT EXTENT POOL 门 锁 。 

新 的 临时 表 空 间 管理 算法 不 需要 频繁 地 分 配 和 释放 临时 段 ， 这 大 大 提高 了 临时 段 管 理 的 效 
率 。 由 于 这 是 一 种 只 分 配 不 释放 的 算法 ， 因 此 DBA 经 常会 看 到 自己 的 临时 表 空 间 总 是 处 于 或 者 
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接近 100% 使 用 的 状态 。 其 实 对 于 7.3 以 后 的 版 本 而 言 ， 临 时 表 空 间 使 用 率 接近 100% 是 十 分 正 
常 的 ，DBA 可 以 通过 V$SORT USAGE 和 V$SORT. SEGMENTS 这 两 个 视图 来 检查 临时 段 的 使 
用 情况 。 

在 RAC/OPS 环境 下 , 临时 段 的 管理 算法 也 是 类 似 的 。 在 RAC 中 ,由 于 多 个 实例 会 共享 一 个 
临时 表 空 间 , 因 此 这 些 实例 也 能 够 共享 相同 的 扩展 ,在 RAC 环境 下 ,每 个 实例 都 拥有 独立 的 SEP, 
各 个 实例 中 的 排序 操作 需要 在 自己 的 SEP 中 分 配 空间 。 如 果 SEP 中 无 法 分 配 到 足够 的 空间 ， 那 
么 首先 会 在 表 空间 中 分 配 ; 而 如 果 表 空间 也 已 经 分 配 完毕 ， 这 时 若 其 他 的 实例 还 有 空闲 的 扩展 ， 
那么 这 个 扩展 就 可 以 分 配给 需要 的 实例 使 用 。 这 些 操作 都 是 不 可 见 的 ， 虽然 SERVER 进程 不 会 
收 到 ORA-1652 的 错误 信息 ， 但 是 在 ALTER LOG 中 会 有 一 个 ORA-1652 的 记录 。 


7.1.2 PGA 和 排序 


PGA 使 用 的 空间 是 独立 于 SGA 的 ， 主 要 用 来 进行 排序 、 表 连接 等 操作 。 一 般 来 说 ， 根 据 系 
统 配置 和 应 用 软件 的 不 同 , 可 以 把 物理 内 存 的 15% ~ 30% 用 于 РСА 空间 。PGA 中 的 SQL 工作 区 
域 对 于 系统 的 性 能 影响 很 大 ， 配 置 合理 的 SQL 工作 区 域 参数 对 于 调整 系统 性 能 具有 十 分 重要 的 
作用 。Oracle 9i 提供 的 自动 PGA 内 存 管 理 功能 ， 可 以 帮助 我 们 更 加 灵活 地 使 用 和 管理 PGA。 

大 多 数 SQL 操作 都 与 数据 排序 相关 ， 特 别 是 对 数据 的 统计 和 分 析 。 排 序 和 数据 库 的 性 能 3 
系 密切 。 在 下 列 情况 下 会 发 生 排序 操作 。 

о 创建 索引 : CREATE INDEX 语句 会 引起 服务 进程 ( 对 于 并 行 操作 ， 是 从 属 进程 在 进行 操 

YE) 对 索引 字段 进行 排序 ， 并 创建 B 树 。 当 排序 结束 的 时 候 ， 会 在 索引 的 目的 表 空 间 中 
创建 临时 段 来 存放 结果 ， 在 索引 创建 完毕 后 ， 临 时 段 会 被 转 为 索引 段 。 
О 在 SELECT 语句 中 的 order by 或 者 group by 子 句 。 
О 在 SELECT 语句 中 使 用 distinct 关键 字 。 
口 在 查询 中 使 用 UNION. INTERSECT 或 者 MINUS 操作 , 这 些 操作 会 导致 服务 进程 查找 重 
复 的 记录 。 
口 SORT-MERGE 连接 : 如 果 在 等 于 连接 中 缺乏 合适 的 索引 ， 那么 连接 操作 会 产生 一 个 全 表 
扫描 操作 ， 并 且 通 过 排序 后 的 合并 操作 来 完成 连接 操作 。 
О ANALYZE 语句 : ANALYZE 语句 执行 时 会 排序 数据 ， 用 以 生成 汇总 数据 。 
口 其 他 的 一 些 操作 也 可 能 产生 排序 操作 ， 比 如 create primary key、enable constraint、create 
table, create table as select 等 。 
排序 操作 需要 分 配 内 存 空间 ， 这 部 分 内 存 空间 称 为 SORT_AREA。 在 使 用 PGA 自动 管理 的 
系统 中 ，SORT_AREA 被 自动 管理 ,否则 ， 由 SORT AREA SIZE 参数 限定 每 个 会 话 使 用 
SORT AREA 的 最 大 数量 (单位 是 字 节 )。 

在 PGA 手工 管理 的 模式 下 ， 对 于 每 个 会 话 而 言 ， 在 排序 发 生 时 ， 会 立即 分 配 一 部 分 内 存 ， 
随 着 排序 操作 的 进行 , 内 存 会 不 断 增长 , 直到 排序 操作 完成 或 者 达到 本 会 话 能 够 使 用 的 排序 空间 
的 最 大 值 。 当 排序 完成 后 ， 如 果 使 用 的 排序 内 存 空间 大 于 SORT. AREA. RETAINED SIZE 参数 
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指定 的 大 小 , 那么 部 分 空间 会 被 释放 ， 而 由 这 个 参数 指定 了 大 小 的 内 存 空间 会 被 会 话 保留 ， 以 便 

用 于 下 次 排序 。 当 服务 进程 退出 系统 的 时 候 ， 排 序 空间 被 完全 释放 ， 并 归还 给 系统 。 

当 为 排序 рете s 间 已 经 达到 了 SORT. AREA, SIZE 参数 指定 的 大 小 ,而 排序 操作 仍 未 完成 ， 
还 需要 继续 使 用 排序 空间 时 , 那么 已 经 排序 的 行 会 被 写 人 磁盘 ,然后 释放 使 用 过 的 排序 空间 , IE 
后 面 还 没有 完成 的 排序 操作 使 用 。 服 务 进 程 会 在 临时 表 空 间 中 创建 临时 段 来 存放 这 些 数据 , 今后 
对 于 这 些 行 的 排序 操作 ， 需 要 访问 磁盘 。 这 些 排 序 使 用 的 临时 段 一 般 存 储 在 临时 表 空 间 中 , 也 可 
以 存储 在 永久 性 表 空 间 中 。 

排序 使 用 的 临时 段 会 在 数据 库 发 生 第 一 次 排序 操作 时 , 在 临时 表 空 间 中 被 创建 。 多 个 需要 在 
磁盘 中 排序 的 事务 可 以 共享 同一 个 排序 段 ， 但 是 它们 不 使 用 相同 的 扩展 (extent )。 排 序 使 用 的 扩 
展 在 实例 关闭 以 前 不 会 自动 释放 , 但 是 会 被 标注 为 空闲 状态 ， 以 便 其 他 排序 操作 使 用 。 因 此 , 在 
数据 库 启动 后 ， 临 时 表 空 间 的 空闲 空间 会 持续 下 降 。Oracle 数据 库 把 排序 段 的 信息 存储 在 SEP 
(Sort Extent Pool， 排 序 扩展 池 ) rB, SEP 是 SGA 中 的 一 — 每 个 需要 使 用 临时 表 空 间 
进行 排序 的 SQL 语句 都 会 检查 SEP， 去 查找 可 使 用 的 空闲 扩展 。 后 台 进 程 SMON 会 在 数据 库 实 
例 启 动 的 时 候 , 在 数据 库 被 打开 后 释放 所 有 的 排序 段 , 这 就 是 — и SMON 会 占用 
KE CPU 资源 的 原因 。 这 种 操作 可 以 避免 由 临时 表 空 间 的 碎片 化 所 导致 的 性 能 问题 。 

基于 Oracle 排序 操作 的 特点 ， 对 于 临时 表 空 间 的 设置 ， 提 出 如 下 的 建议 。 

а 在 系统 中 使 用 多 个 临时 表 空 间 ， 以 避免 数据 访问 冲突 。 在 Oracle 10g 或 者 11g 版 本 中 ,可 

以 使 用 排序 表 空 间 组 。 

a 把 临时 表 空 间 的 文件 分 散 到 多 个 磁盘 上 ， 以 提高 排序 操作 的 性 能 。 

口 对 于 复杂 的 系统 ， 可 以 创建 多 个 存储 参数 完全 不 同 的 临时 表 空 间 ， 供 不 同 特性 的 排序 操 

作 使 用 。 

O 在 Oracle 9i 及 以 后 的 版 本 中 ,使 用 本 地 管理 表 空 间作 为 临时 表 空 间 。 在 Oracle 9i 以 前 的 
版 本 中 ， 临 时 表 空间 的 存储 参数 设置 为 INITIAL=NEXT， 因 为 每 次 写 人 磁盘 的 数据 量 基 
本 上 是 一 致 的 (等 于 SORT. AREA SIZE, 在 自动 PGA 管理 中 ， 等 于 系统 允许 会 话 使 用 
的 SQL 工作 区 的 最 大 值 )。 可 以 这 样 计 算 INITIAL 的 值 ， 等 于 或 者 略 大 于 nx 
SORT AREA SIZE + DB_BLOCK_SIZE。 采 用 这 种 设置 ， 每 个 扩展 都 可 以 存放 一 次 排序 
操作 所 需要 的 空间 ( 这 只 是 一 种 建议 的 设置 ， 在 大 多 数 情况 下 可 以 满足 系统 的 要 求 ， 但 

并 不 一 定 在 所 有 的 场合 下 都 会 提高 系统 的 性 能 

а 如 果 一 张 表 是 按照 某 个 键 值 的 升序 装载 的 ， 那 么 在 创建 索引 的 时 候 可 以 使 用 NOSORT 子 

句 来 避免 不 必要 的 排序 。 

а 对 于 并 行 查询 ， 每 个 查询 会 使 用 比 普通 查询 更 多 的 排序 区 资源 。 

а 由 于 磁盘 排序 的 效率 比 内 存 排 序 低 很 多 CI. 100 倍 以 上 ), 因此 需 设置 合理 的 SQL 排序 区 
大 小 ， 并 尽量 避免 在 排序 中 出 现 磁 盘 操 作 。 对 于 ОПР 系统 ， 设 置 足够 大 的 РСА 空间 可 
以 使 系统 的 内 存 排序 比例 超过 99% 。 

从 V$SORT_SEGMENT 中 可 以 查看 到 临时 表 空 间 中 排序 段 的 情况 。 通 过 下 列 代 码 所 示 的 
SQL 语句 可 以 查看 当前 临时 段 的 使 用 情况 : 


71 基本 概念 187 


SELECT tablespace name, extent size, total extents, used extents 
free extents, max used size 
FROM v$sort segment 


当 排 序 正 在 进行 时 ， 我 们 可 以 看 到 下 面 的 结 
TABLESPACE NA EXTENT SIZ TOTAL EXTE USED EXTEN FREE EXTEN MAX USED S 


ТЕМРО1 9 25 13 12 20 
1 гом selected. 


排序 结束 后 ， 结 果 如 下 : 
TABLESPACE NA EXTENT SIZ TOTAL EXTE USED EXTEN FREE EXTEN MAX USED S 


TEMP01 9 25 0 25 20 
1 row selected. 


可 以 看 出 ,排序 后 ，TEMP01 的 段 中 共有 25 个 扩展 ， 当 排序 进行 的 时 候 使 用 了 13 个 ， 剩 余 
12 个 空闲 扩展 ， 当 排序 结束 后 ，25 个 扩展 都 处 于 空闲 的 状态 。 如 果 要 查看 当前 的 某 个 数据 库 用 
户 使 用 了 多 少 临时 段 室 间 ， 可 以 通过 查询 V$SORT_USAGE fll V$SESSION ЗЕ; 


SELECT s.username, u.tablespace, u.contents, u.extents, u.blocks 
FROM v$session s, v$sort usage u 
WHERE s.saddr=u.session_addr 


如 果 test 用 户 正 在 做 一 个 排序 ， 那 么 会 出 现 如 下 结 
USERNAME TABLESPACE CONTENTS EXTENTS — BLOCKS 


TEST TEMP01 TEMPORARY 13 130 
1 row selected. 


当 排序 结束 的 时 候 ，V$SORT_USAGE 中 的 数据 将 被 清除 ， 分 配 的 扩展 也 就 归还 了 。 


7.1.8 PGA 和 PGA AGGREGATE TARGET 


在 Oracle 数据 库 中 ， 和 PGA 相关 的 参数 包括 : 

口 PGA_AGGREGATE_TARGET (9i+), PGA 能 够 使 用 的 最 大 内 存 空间 ; 

О WORKAREA_SIZE_POLICY ( 9i+ ), 分 配 SQL 工作 区 域 的 规则 ， 可 以 取 值 AUTO 或 者 
MANUAL; 

口 SORT_AREA_SIZE， 定 义 每 个 会 话 可 以 用 于 内 存 排序 的 空间 的 最 大 值 ; 

口 HASH_AREA_SIZE， 定 义 每 个 会 话 可 以 用 于 哈 希 连接 的 内 存 空间 的 最 大 值 ; 

О BITMAP_MERGE_AREA_SIZE, 定义 每 个 会 话 使 用 位 图 合并 连接 时 的 内 存 工作 区 域 的 最 


大 值 ; 
口 CREATE BITMAP AREA, SIZE, 定义 每 个 会 话 创建 位 图 时 可 以 使 用 的 内 存 工 作 区 域 的 最 
大 值 。 


可 以 根据 实际 应 用 的 需要 ， 来 设置 PGA AGGREGATE TARGET 参数 。 对 于 ОТР ZZ, 
一 般 不 超过 物理 内 存 的 20% 。 但 这 个 规则 不 是 绝对 的 ,具体 的 值 可 以 根据 AWR 或 者 STATSPACK 
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报告 的 建议 来 设置 。 如 果 将 WORKAREA_SIZE_POLICY 设置 为 AUTO ( Oracle 9; 或 以 后 的 版 本 
才 支 持 )， 那 么 就 不 需要 设置 * AREA SIZE 参数 了 ，Oracle 会 自动 管理 。( 在 Oracle 9; 版 本 中 , 
РСА 自动 管理 仅 对 独立 服务 器 模式 的 会 话 有 效 ， 共 享 服务 器 模式 的 会 话 还 需要 使 用 
* AREA, SIZE 参数 ; 从 Oracle 10g 版 本 开始 ，PGA 自动 管理 对 两 种 模式 的 会 话 都 有 效 。) 

对 于 大 型 的 查询 操作 ， 其 性 能 取决 于 PGA 的 各 个 工作 区 域 的 设置 。 总 的 来 说 , 大 的 SQL 工 
作 区 域 会 提高 查询 的 性 能 ， 不 过 会 消耗 比较 大 的 内 存 。 当 SQL 工作 区 域 充 足 的 时 候 ， 所 有 的 相 
关 操 作 都 可 以 在 内 存 中 完成 。 当 SQL 工作 区 域 不 足 的 时 候 ， 需 要 在 临时 表 空间 中 分 配 空间 来 完 
成 操作 ， 因 此 性 能 会 受到 很 大 的 有 影响。 在 内 存 资源 不 是 很 充足 的 系统 中 ,调整 SQL 工作 区 域 是 
一 项 极 具 挑战 的 工作 。 

在 Oracle 9i 版 本 以 前 的 数据 库 中 , 管理 РСА 是 十 分 复杂 的 工作 。 需要 DBA 非常 谨慎 地 配置 
各 个 AREA. SIZE 参数 。 而 Oracle 9i 提 供 了 一 种 全 自动 管理 PGA 的 方法 ， 只 要 把 WORKAREA 
_SIZE_POLICY 参数 设置 为 AUTO, 并 且 设 置 一 个 合适 的 PGA_AGGREGATE_TARGET 值 ,Oracle 
数据 库 就 会 自动 管理 PGA 的 各 个 工作 区 域 。 

PGA_AGGREGATE_TARGET 参数 值 的 设置 并 不 是 按照 完全 固定 的 方法 来 完成 的 。MOS 上 
的 一 篇 官方 文档 提出 了 一 种 具有 一 定 普遍 性 的 设置 方式 : 对 于 OLTP 系统 , 设置 该 值 为 物理 内 存 
的 15% ~ 20%; 而 对 于 OLAP 系统 ， 则 设置 为 物理 内 存 的 40% 。 实 际 上 ， 对 于 具体 的 系统 来 说 ， 
设置 该 参数 并 不 是 那么 简单 的 ， 要 根据 当前 系统 的 现状 来 设置 才 有 针对 性 。 

通过 V$PGASTAT 可 以 得 到 一 些 调整 PGA_AGGREGATE_TARGET 参数 的 参考 资料 。 比 如 : 
SQL>SELECT * FROM V$PGASTAT 


NAME VALUE 

aggregate PGA target parameter 524288000 bytes 
aggregate PGA auto target 463435116 bytes 
global memory bound 25600 bytes 
total PGA inuse 9353216 bytes 
total PGA allocated 73516032 bytes 
maxi mum PGA allocated 698371072 bytes 
total PGA used for auto workareas 0 bytes 

maxi mum PGA used for auto workareas 560744448 bytes 
total PGA used for manual workareas 0 bytes 


maxi mum PGA used for manual workareas 0 bytes 

over allocation count 0 bytes 

total bytes processed 4.0072Е+10 bytes 
3 
5 


total extra bytes read/written .1517E4*10 bytes 
cache hit percentage 5.97 percent 


主要 的 状态 信息 包括 如 下 几 项 。 

О aggregate PGA auto target: 可 调整 的 PGA 空间 ， 只 有 这 部 分 空间 可 以 被 Oracle 自动 调整 
功能 使 用 ， 并 用 于 各 种 SQL 工作 区 域 。 这 部 分 空间 应 该 占 PGA_AGGREGATE_TARGET 
中 的 最 大 比重 ， 如 果 太 小 ， 会 引起 性 能 问题 。 

口 total PGA used for auto workarea: 系统 使 用 的 可 调整 的 PGA 空间 ，maximum PGA used for 
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auto workareas 显示 系统 启动 后 使 用 可 调整 PGA 的 最 大 值 。 

О total PGA in used: 目前 PGA 空间 的 使 用 情况 ， 这 个 值 和 V$PROCESS 中 的 PGA_USED _ 

MEM 相同 。 

О over allocation count: 这 个 值 只 在 Oracle 9i R2 版 本 中 出 现 ， 如 果 PGA_AGGREGATE_ 
TARGET 的 值 设 置 得 过 小 ,Oracle 会 分 配额 外 的 空间 用 于 РСА, 这 个 值 将 会 大 于 0, 此 时 
应 该 调整 PGA_AGGREGATE_TARGET 参数 ， 使 这 个 值 为 0 或 者 接近 于 0。 

口 cache hit percentage: 这 个 值 只 在 Oracle 9i R2 版 本 中 出 现 ， 它 指明 了 РСА 的 性 能 。 如 果 
这 个 值 是 100% ， 说 明 РСА 空间 是 足够 的 ， 都 可 以 用 优化 模式 (optimal ) 来 完成 操作 。 
当 PGA 空 间 不 足 时 ，Oracle 需要 使 用 外 部 辅助 空间 ， 结 合 One-Pass 或 Multi-Pass 模式 来 
完成 操作 ， 此 时 系统 的 性 能 将 受到 影响 ， 该 值 的 计算 公式 为 : 


total bytes processed * 100 
PGA Cache Hit Ratio = -------- A AAA ác 


(total bytes processed + total extra bytes read/written) 
fii] V$SQL WORKAREA HISTOGRAM 视图 可 以 查看 系统 中 PGA 的 详细 使 用 细 情 况 ， 该 
视图 中 列 出 了 工作 区 域 使 用 优化 模式 、One-Pass 模式 和 Multi-Pass 模式 的 统计 值 ， 比 如 : 


SELECT LOW OPTI MAL SIZE/1024 low kb, (HI GH OPTI МАЕ SIZE+1)/1024 high kb, 
opti mal executions, onepass executions, multipasses executions 

FROM  v$sql workarea histogram 

WHERE total executions != 0; 


LOW KB HI GH KB OPTI MAL EXECUTI ONS ONEPASS EXECUTIONS MULTIPASSES EXECUTI ONS 


8 16 156255 0 0 
16 32 150 0 0 
32 64 89 0 0 
64 128 13 0 0 
128 256 60 0 0 
256 512 8 0 0 
512 1024 657 0 0 
1024 2048 551 16 0 
2048 4096 538 26 0 
4096 8192 243 28 0 
8192 16384 137 35 0 
16384 32768 45 107 0 
32768 65536 0 153 0 
65536 131072 0 73 0 
131072 262144 0 44 0 
262144 524288 0 22 0 


从 上 面 的 数据 可 以 看 出 , 使 用 8 ~ 1024 KB 空间 的 所 有 操作 都 是 优化 模式 的 , 1024 ~ 2048 KB 
的 空间 中 有 551 次 操作 是 优化 模式 的 ,16 次 操作 是 One-Pass 模式 的 ,没有 Multi-Pass 模式 的 操作 。 
另外 , 我 们 在 STATSPACK 报告 中 也 可 以 看 到 这 个 查询 的 数据 ,不 过 STATSPACK 报告 中 的 数据 
只 是 两 个 SNAPSHOT 之 间 的 统计 信息 ， 而 这 个 视图 中 的 数据 是 从 系统 启动 到 目前 的 统计 值 。 
通过 这 个 视图 也 可 以 计算 各 种 访问 方式 的 百分比 ， 如 下 列 代码 所 示 。 
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SELECT optimal count, round(optimal count*100/total, 2) optimal perc 
onepass count, round(onepass count*100/total, 2) onepass perc 
multipass count, round(multipass count*100/total, 2) multipass perc 
FROM 
(SELECT decode(sum(total executions)], 0, 1, sum(total executions]) total, 
sum( OPTI MAL EXECUTI ONS) opti mal count 
sum(ONEPASS EXECUTIONS) onepass count 
sum MULTI PASSES EXECUTIONS) multipass count 
FROM  v$sql workarea histogram 
WHERE low optimal size > &nk*1024); -- nk 是 参数 


通过 V$SQL_WORKAREA_ACTIVE 视图 ， 可 以 查看 到 当前 活跃 的 PGA 工作 区 。 


SELECT to number(decode(SID, 65535, NULL, SID)) sid 
operation type OPERATI ON, trunc( EXPECTED SIZE/1024) ESIZE 
trunc( ACTUAL MEM USED/1024) MEM, trunc( MAX MEM USED/1024) "MAX MEM" 


NUMBER PASSES PASS, trunc(TEMPSEG SIZE/1024) TSIZE 
FROM V$SQL WORKAREA ACTI VE 
ORDER BY 1,2; 
SID OPERATI ON ESI ZE MEM MAX MEM PASS TSIZE 
8 GROUP BY (SORT) 315 280 904 0 
8 HASH- J OIN 2995 2311 2430 1 20000 
9 GROUP BY (SORT) 34300 22688 22688 0 
11 HASH-J OIN 18044 54482 54482 0 
12 HASH-J OIN 18044 11406 21406 1 120000 


从 上 例 可 以 看 出 , SID 为 8 的 会 话 在 进行 HASH 连接 , 采用 的 是 One-Pass 模式 , 使 用 了 2377 
KB 的 PGA 内 存 , 最 大 使 用 了 2430 KB 的 PGA 内 存 , 并 且 使 用 了 20000 KB 的 临时 表 空 间 。ESIZE 
字段 显示 的 是 PGA 内 存 管 理 器 允许 该 会 话 使 用 的 最 大 工作 空间 的 大 小 。 当 SQL 语句 执行 完毕 后 ， 
工作 区 域 就 会 自动 被 释放 。 

工作 区 域 的 大 小 取决 于 PGA_AGGREGATE_TARGET 参数 的 值 。Oracle 9i R2 版 本 还 提供 了 
V$PGA_TARGET_ADVICE 和 V$PGA_TARGET_ADVICE_HISTOGRAM 视图 , 可 以 帮助 用 户 来 
选择 合适 的 PGA_AGGREGATE_TARGET 值 . 当 STATISTICS_LEVEL 设置 为 TYPICAL 或 者 ALL 
的 时 候 ，Oracle 数据 库 会 生成 这 两 个 视图 的 数据 。 相 关 查 询 示 例如 下 : 

SELECT round(PGA TARGET FOR ESTI MATE/ 1024/1024) target mb 

ESTD PGA CACHE HIT PERCENTAGE cache hit perc 


ESTD OVERALLOC COUNT 
FROM v$pga target advice; 


TARGET MB CACHE HIT PERC ESTD OVERALLOC COUNT 


63 23 367 
125 24 30 
250 30 3 
315 39 0 
500 58 0 
600 59 0 
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700 59 
800 60 
900 60 
1000 61 
1500 67 
2000 16 
3000 83 
4000 85 


这 个 查询 的 结果 列 出 了 当 PGA_AGGRATE TARGET 的 取 值 为 TARGET. MB H}, PGA 的 命 

中 率 和 OVERALLOC 的 值 。 选 择 一 个 OVERALLOC 尽量 接近 于 0， 命 中 率 尽 量 接近 于 100% , 

并 且 系 统 内 存 容 量 足 以 支持 的 合理 值 作 为 PGA_AGGREGATE TARGET 的 参数 值 。 

使 用 PGA 自动 管理 还 应 该 注意 以 下 问题 。 

о 当 设置 PGA_AGGREGATE_TARGET 和 WORKAREA_SIZE_ POLICY=AUTO 后 , 所 有 的 

* AREA, SIZE 参数 都 会 被 系统 忽略 ( 仅 针对 独立 服务 器 模式 ， 在 Oracle 11g 版 本 之 前 ， 
共享 服务 器 模式 下 只 能 使 用 PGA 手动 管理 )。 

О 对 于 Oracle 8i 或 者 更 早 的 版 本 ,PGA 空间 是 静态 的 , 当 进 程 启动 并 且 分 配 了 РСА 空间 后 ， 
这 些 空间 不 会 自动 释放 ， 除 非 会 话 结束 。 如 果 操 作 系统 内 存 不 足 ， 可 能 会 导致 系统 的 换 
页 操作 。 因 此 ， 将 *_AREA_SIZE 参数 设置 得 过 大 会 导致 大 量 内 存 被 使 用 。 在 Oracle 9i 
版 本 使 用 自动 PGA 管理 后 ，Oracle 会 将 进程 分 配 的 PGA 空间 中 目前 不 使 用 的 空间 回收 ， 
并 分 配给 其 他 进程 使 用 ， 这 样 可 以 提高 工作 区 空间 的 使 用 率 ， 减少 内 存 浪费 。 

a 使 用 自动 PGA 内 存 管理 机 制 可 以 限制 每 个 Oracle 进程 使 用 的 总 内 存 的 数量 ,从 而 使 内 存 

的 使 用 率 更 高 。 

о 由 于 能 够 动态 分 配 工作 区 空间 ， 因 此 可 以 大 幅 减 少 ORA-4030 错误 的 发 生 。 

О 如 果 ESTD OVERALLOCATION COUNT( V$PGA, TARGET. ADVICE VIEW 中 的 字段 ) 

的 值 非 0， 说 明 PGA_AGGREGATE_ TARGET 的 值 太 小 。 

О 如 果 РСА AGGREGATE TARGET 的 值 过 小 ， 会 导致 SQL*Loader 数据 装载 速度 大 幅度 
减 慢 ， 因 此 部 分 用 户 反 映 ，Oracle 9i 中 SQL*Loader 的 速度 比 8i 慢 , 这 主要 是 因为 没有 合 
理 地 设置 PGA_AGGREGATE_TARGET 参数 。 

口 VMS 操作 系统 不 支持 PGA 自动 管理 。 

О {Е HP-UX 11.0 下 设置 PGA 自动 管理 会 导致 操作 系统 出 现 错误 (PANIC )， 这 是 由 
bug:2122307 引起 的 。 


о о о c c c c c 


7.1.4 你 应 该 知道 的 PGA 自动 管理 内 幕 


在 Oracle 9i 之 前 ， 设 置 合理 的 *_AREA_SIZE 是 DBA 的 重要 职责 ， 这 也 是 最 具有 挑战 性 的 
工作 之 一 。Oracle 9i 的 自动 PGA 管理 ， 可 以 减轻 DBA 管理 *_AREA_SIZE 的 工作 。Oracle 根据 
一 定 的 规则 为 每 个 会 话 自动 分 配 SQL 的 工作 区 域 空间 。 

Oracle 进行 PGA 自动 管理 时 有 一 项 基本 的 原则 ， 每 个 会 话 分 配 到 的 SQL 工作 区 域 空 间 不 超 
过 PGA_AGGREGATE_TARGET 参数 指定 空间 的 5%。 对 于 并 行 操作 ，Oracle 为 每 个 会 话 分 配 的 
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SQL 工作 区 域 不 超过 PGA_AGGREGATE_TARGET 参数 指定 空间 的 30% 。 而 对 于 并 行 处 理 的 操 
作 ， 每 个 子 作 业 占 用 的 SQL 工作 区 域 不 超过 “( PGA_AGGREGATE TARGET 指定 空间 x 30% ) 
+ FTR”. 

实际 上 ， 每 个 会 话 可 分 配 到 的 PGA 空间 还 受 一 个 隐 含 参数 的 限制 ， 这 个 参数 就 是 
_pga_max_size， 其 默认 值 是 200 MB, ， 如 果 我 们 想 要 使 用 更 大 的 PGA 内 存 ， 那 么 就 需要 加 大 这 
个 参数 。 不 过 ， 在 一 个 经 常 使 用 并 行 查询 的 系统 中 加 大 _pga_max_size 参数 是 存在 风险 的 ， 需 要 
确保 物理 内 存 足 够 支撑 大 量 的 PGA 需求 ， 否 则 系统 就 会 出 现 由 ORA-4030 错误 导致 的 问题 。 

很 多 DBA 对 PGA_AGGREGATE_TARGET 参数 存在 误解 ， 认 为 这 个 参数 设 定 的 是 分 配给 
РСА 的 空间 大 小 ,实际 上 并 不 是 这 样 的 , PGA_AGGREGATE_TARGET 参数 只 是 设 定 了 一 个 PGA 
分 配 时 用 于 计算 PGA 的 参考 值 。 在 SQL 执行 计划 分 析 的 时 候 ， 如 果 需 要 产生 排序 ， 那么 系统 会 
根据 PGA_AGGREGATE_TARGET 的 值 估算 排序 区 的 空间 ， 并 且 完 成 排序 区 空间 的 分 配 工作 。 
如 果 在 SQL 的 执行 过 程 中 ,分 配 的 PGA 排序 区 出 现 不 足 ， 那 么 系统 就 会 进行 硬盘 排序 ， 而 不 会 
重新 从 PGA 中 再 度 分 配 空间 。 因 此 我 们 经 常会 看 到 РСА 使 用 率 很 低 , 但 是 有 很 多 小 型 排序 也 使 
用 了 One-Pass 模式 ， 相 关 示 例如 表 7-1 所 示 。 


表 7-1 
PGA Aggr Ашо PGA РОА Мет М/А PGA %PGA %Auto %Man Global Mem 
Target(M) Target(M) Alloc(M) Used(M) М/А Мет М/А Мет М/А Мет Bound(K) 
B 20 480 17 136 1 669.67 0.00 0.00 0.00 0.00 10 240 000 


E 20 480 17 114 1 702.74 3.00 0.18 100.00 0.00 10 240 000 


M Een EUER IH, PGA, AGGREGATE TARGET 参数 设置 为 了 20GB, 根据 BEGIN ЯП END 
两 个 采样 点 的 系统 中 的 会 话 情况 , 计算 出 来 的 AUTO PGA 的 大 小 分 别 为 17136MB 和 17114 MB, 
这 个 值 没 有 达到 PGA_AGGREGATE_TARGET 的 设 定 值 ， 实 际 分 配 的 РСА 内 存 是 1669 MB 和 
1702 MB ， 均 小 于 估算 的 PGA 大 小 。 下 面 我 们 来 分 析 表 7-2 所 示 的 数据 。 


表 7-2 
Low Optimal High Optimal Total Execs Optimal Execs 1-Pass Execs M-Pass Execs 
2K 4K 179 830 179 830 0 0 
64K 128K 810 810 0 0 
128K 256K 372 372 0 0 
256K 512K 517 517 0 0 
512K 1024K 23191 23 191 0 0 
1M 2M 686 686 0 0 
2M 4M 590 247 343 0 
4M 8M 23 19 0 
8M 16M 9 9 0 
16M 32M 5 1 4 0 
512M 1024M 74 0 74 0 
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从 上 表 可 以 看 出 , 有 343 次 2~4MB 的 小 排序 也 使 用 了 1-PASS 排序 。 而 8 ~ 16 MB 的 略 大 排 
序 反而 是 在 内 存 中 完成 的 。 经 过 分 析 ， 我 们 发 现 系统 中 存在 一 些 connect by 树 状 查 询 ， 对 于 这 类 
查询 ，Oracle 优化 器 在 评估 排序 区 大 小 的 时 候 ， 往 往 会 出 现 偏差 ， 如 果 预 先 分 配 的 缓冲 区 略 小 ， 
那么 就 会 出 现 大 量 的 硬盘 排序 。 在 这 个 案例 中 ,我 们 可 以 将 PGA_AGGREGATE TARGET 从 20 GB 
加 大 到 30 СВ, ， 这 样 就 大 幅 缓解 了 这 个 问题 。 
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在 目前 PGA 自动 管理 的 模式 下 ，PGA 优化 相对 较为 简单 ， 只 要 设置 合理 的 
PGA AGGREGATE TARGET 参数 值 ， 基 本 就 能 够 达到 目的 。 一 般 来 说 ，PGA 优化 的 要 点 就 是 
在 物理 内 存 足 够 的 情况 下 ， 尽 可 能 多 地 使 用 РСА 内 存 , 减少 硬盘 排序 ， 如 图 7-1 所 示 。 


图 7-1 


优化 排序 使 用 较 多 的 物理 内 存 ， 但 是 有 最 好 的 响应 时 间 。 我 们 可 以 通过 AWR 报告 或 者 
STATSPACK 报告 来 判断 PGA 是 否 存 在 问题 ， 相 关 示 例如 图 7-2 所 示 。 


A 
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如 果 In-memory Sort 的 指标 小 于 100% ， 就 说 明 РСА 存在 一 定 的 硬盘 排序 。 下 面 我 们 根据 如 
下 PGA 命中 率 进一步 分 析 。 


PGA Aggr Summary 
-> PGA cache hit % - 


DB/I nst: SFOSS/sfoss2 
WA (WorkArea) 


Snaps: 12838-12839 


percentage of data processed only in-memory 


PGA Cache Hit % 


WA MB Processed 


Extra WA MB Read/Written 


我 们 可 以 看 到 PGA 的 命中 率 是 98.4%， 这 个 比例 算是 比较 高 了 。 但 命中 率 高 并 不 等 于 没有 
可 题 ， 在 理想 的 情况 下 ,可 以 让 PGA 的 命中 率 达 到 100% ， 实 现 完全 的 内 存 排序 ， 以 获得 最 佳 的 
接 下 来 ， 我 们 可 以 通过 如 下 所 示 的 PGA 排序 柱状 图 来 判断 是 否 存 在 问题 


Low High 
Optimal Opti mal Total Execs Optimal Execs 1-Pass Execs M-Pass Execs 
2K 4K 2,097,268 2,097,268 0 0 
64K 128K 7,485 7,485 0 0 
128K 256K 5,214 5,214 0 0 
256K 512K 4,155 4,155 0 0 
512K 1024K 394,849 394,839 10 0 
1M 2M 4,695 4,695 0 0 
2M 4M 116 538 238 0 
4M 8M 317 139 178 0 
8M 16M 218 88 130 0 
16M 32M 148 74 74 0 
32M 64M 4 4 0 0 


从 柱状 图 中 可 以 看 出 ， 一 些 很 小 的 排序 也 使 用 了 硬盘 排序 Ж Ж PGA_AGGREGATE_ 
TARGET 参数 确实 有 些 偏 小 了 。 那么 如 何 调整 这 个 参数 呢 ? 接 下 来 , 查看 STATSPACK 报告 中 的 
PGA 建议 ， 如 图 7-3 所 示 。 


Estd Extra Estd PGA — Estd PGA 

PGA Target Size W/A MB WA MB Read/ Cache Overalloc 
Est (MB) Factr Processed Written to Disk Hit 9 Count 
1, 280 omi 113, 513, 637. 6 5, 198, 930. 2 96.0 350, 462 

2, 560 0.3 113, 513, 637.6 1, 154, 187. 9 99.0 93, 607 

5, 120 it] 113, 513, 637. 6 932112595 99.0 63, 379 

7, 680 0.8 113, 513, 637. 6 552, 639. 5 99.0 37, 120 

10, 240 120 113, 513, 637. 6 88, 382. 3 99.0 7,583 
12, 288 152, 113, 513, 637. 6 0.0 100.0 一 0 
14, 336 1.4 113, 513, 637. 6 .0.0 — 100.0 0 
16, 384 1.6 113, 513; 637. 6 0.0 100.0 0 
18, 432 19 113, 513, 637. 6 0.0 100.0 0 
20, 480 2.0 113, 513, 637. 6 0.0 100. 0 0 
30, 720 3.0 113, 513, 637. 6 0.0 100. 0 0 
40, 960 4.0 1135513163156 0.0 100. 0 0 
61, 440 6.0 113, 513, 637. 6 0.0 100.0 0 
81, 920 8.0 113, 513, 637. 6 0.0 100.0 0 


图 7-3 
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不 难看 出 ， 当 PGA, AGGREGATE TARGET 参数 值 为 12288 MB FF, PGA 的 命中 率 可 以 达 
到 100%， 而 且 OVERALLOC COUNT 也 为 0， 因 此 ， 我们 可 以 将 PGA_AGGREGATE_TARGET 
加 大 为 12288 MB, ， 如 果 物 理 内 存 充足 ， 在 调整 PGA 的 时 候 ， 可 以 将 这 个 参数 设置 得 略 高 一 些 ， 
比如 设置 为 14000 MB. 

有 些 时 候 , PGA 的 总 体 设置 没有 问题 , 不 过 偶尔 会 出 现 某 个 SQL 存在 较为 严重 的 硬盘 排序 ， 
这 该 如 何 分 析 呢 ?假设 我 们 知道 这 个 SQL 的 SQL. ID, 那么 就 可 以 通过 代码 清单 7-1 所 示 的 SQL 
进行 查询 。 


代码 清单 7-1 


col op format al5 trunc 

col policy format a8 trunc 

col last format а10 гипс 

set numwidth 8 

ine 200 

Select operation_type as op, operation_id as id, policy, 

round(esti mated optimal size/1024/1024,2) as e opt, 
round(estimated onepass size/1024/1024,2) as e one, 

round(last memory used/1024/1024,2) as | mem, last execution as last, 

total executions as tot, optimal executions as opt, onepass executions as one, 
multipasses executions as mult, 

round(active ti me/ 1000000, 2) as sec, round(max tempseg size/1024/1024,2) as tmp т, 
round(last tempseg size/1024/1024,2) as tmp L 

from v$sql_workarea where sql idz'37qj h5yuha3x9' ; 


[2] 
CD 


具体 示例 如 下 : 

OP E_OPT E ONE L MEM LAST ТОТ OPT ONE MULT SEC ТМВ M TMP L 
SORT (v2) 59.92 2.63 53.26 OPTIMAL 1 1 0 0 289.53 

GROUP BY (HASH) 136.51 8.69 20.1 1 PASS 1 0 1 0 382.3 128 128 


我 们 可 以 从 查询 结果 中 看 到 , 这 个 SQL 进行 了 一 次 排序 操作 , 一 次 group by (HASH ) 操作 ， 
其 中 排序 操作 是 优化 模式 的 ， 使 用 了 约 53 MB 的 内 存 ，group by 操作 是 One-Pass 模式 的 ， 使 用 
T 20 MB 的 内 存 和 128 MB 的 临时 段 。 

如 果 需 要 查看 目前 是 哪些 SQL 使 用 了 较 多 的 临时 段 ,我 们 可 以 使 用 如 代码 清单 7-2 所 示 的 脚 
本 完成 进一步 分 析 。 


代码 清单 7-2 


select sql id,operation type as op, operation id as id, 
round(esti mated opti mal size/1024/1024,2) as e opt, 
round(estimated onepass size/1024/1024,2) as e one, 
round(last memory used/1024/1024,2) as | mem, 

Last execution as last, 

total executions as tot, optimal executions as opt, 
onepass_ executions as one, 

multipasses executions as mult, 

round(active time/1000000,2) as sec, 
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round(max tempseg size/1024/1024,2) as tmp m, 
round(last tempseg size/1024/1024,2) as tmp L 
from v$sql_workarea 
where 
max tempseg size is not null 
order by max tempseg size desc; 


SQL ID oP ID E OPT E ONE L_MEM LAST TOTOPTO M — SEC  TMP_M TMP L 
c940m2fhfdhqb HASH-J OIN 2 2048 33.92 1123.07 1 PASS 1 10 2515.02 3520 3520 
9n9h9vbfsutgf GROUP BY(SORT) 1 1147.91 14.09 97.62 1 PASS 1 1 481.01 1792 1792 
33hqyxbdddcj 6 GROUP BY(HASH) 1 1130.5 28.91 142.9 1 PASS 1 10 2957.31 1088 1088 
czmtvcbdamrüv HASH-J OIN 4 1412.22 34.26 1251.05 1 PASS 1 10 8726.81 768 768 
71mcsly2pguza HASH-J OIN 7 975.08 19.88 432.83 1 PASS 1 10 3071.57 768 768 
41m5kq4hw5f79 GROUP BY(SORT) 13 324.85 7.01 97.62 1 PASS 1 1 376.89 448 448 
gk97kydxcdhf9 GROUP BY(HASH) 2 726. 91 22.47 126.81 1 PASS 1 1 206.21 448 448 
7n1hu6k66a369 HASH-J OIN 13 967.37 16.18 1108.92 1 PASS 1 1 196.07 448 448 
gs4aa3r85upzc GROUP BY(HASH) 1 352.85 14.63 88.09 1 PASS 1 1 270.71 384 384 
cmfzdunmgrlal GROUP BY(HASH) 1 278.17 14.23 36.15 1 PASS 1 1 39.38 320 320 
3j6f35gyq3syd GROUP BY(HASH) 1 321. 92 15.43 42.42 1 PASS 1 1 288.28 320 320 
Otzdnch3vc8tv W NDOW| SORT) 2 355.88 6.1 97.62 1 PASS 2 2 0 29026.58 320 320 
Otzdnch3vc8tv WINDOW SORT) 2 323.88 5.83 97.62 1 PASS 1 1 4853.2 320 320 
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理解 ASM 的 结构 


ASM 技术 的 出 现 曾经 给 DBA 带 来 了 巨大 的 挑战 。 由 于 ASM 像 黑匣子 一 样 ， 我 们 并 不 知道 
里 面 装 的 是 什么 ， 因 此 一 旦 出 现 问题 ， 我 们 就 束手无策 了 。 早 期 使 用 ASM 技术 的 用 户 无 一 例外 
地 都 有 过 深刻 的 教训 。 因 此 , 在 ASM 刚刚 出 现 的 几 年 里 , 老 白 经 常 劝诫 客户 尽 可 能 不 要 使 用 它 。 
随 着 这 些 年 我 们 对 ASM 认识 的 加 深 ， 逐渐 掌握 了 其 内 在 结构 和 原理 ， 也 正 是 这 样 ， 我 们 才 可 以 
很 轻松 地 面 对 客户 系统 中 出 现 的 ASM 问题 ， 使 用 kfed 和 amdu 等 工具 为 客户 解决 问题 ， 拯 救 数 
据 。 在 这 个 过 程 中 ,我们 也 依靠 自己 掌握 的 知识 完成 了 一 些 项 目 。 

仔细 算 一 算 , ASM 出 现 已 经 差不多 10 年 了 , ПН. Oracle 也 会 在 不 远 的 将 来 彻底 抛弃 裸 设备 ， 
ASM 很 可 能 会 成 为 大 多 数 系统 的 首选 。 和 掌握 ASM 内 部 原理 对 于 维护 ASM 磁盘 组 至 关 重 要 ， 
此 老 白 希望 能 够 把 这 些 知 识 传 授 给 大 家 ， 于 是 就 邀请 了 老 储 ( 储 学 荣 ) 来 编写 本 章 。 老 储 在 开发 
数据 扫描 工具 时 曾经 认真 分 析 过 ASM 的 结构 ， 因 此 由 他 来 编写 这 一 章 ， 是 最 为 合适 的 。 和 希望 每 
个 维护 ASM 磁盘 组 的 DBA 都 能 够 认真 阅读 下 面 的 内 容 ， 并 自己 尝试 进行 一 些 测 试 ， 本 章 所 介 
绍 的 内 容 将 为 你 提供 很 大 的 帮助 。 


8.1 什么 是 ASM 


以 前 的 DBA 一 般 都 有 这 样 的 经 验 : 将 表 和 索引 分 别 建 在 不 同 的 表 空 间 对 改善 IO 性 能 是 有 
好 处 的 。 但 如 何 规 划 表 空间 及 其 包含 的 数据 文件 却 让 人 头疼 不 已 。 系 统 上 线 后 经 常 发 现 磁 盘 访 问 
热度 不 一 ， 有 的 很 忙碌 ， 经 常 高 居 100%, MAREAREN, UO 瓶颈 很 难得 到 彻底 解决 。 
为 了 帮助 用 户 解决 这 一 问题 ,Oracle 10g 推 出 了 全 新 的 数据 库存 储 技术 一 一 ASM( 自动 存储 管理 )。 
它 主要 用 于 解决 数据 库 文件 的 配置 、 管 理 和 性 能 难题 。 我 们 知道 ，Oracle 数据 库 是 由 一 系列 文件 
构成 的 ， 主 要 包括 参数 文件 、 控 制 文件 、 日 志文 件 、 数 据 文件 、 归 档 日 志 等 。 在 规划 数据 库 时 ， 
数据 库 文件 的 设计 对 性 能 的 影响 很 大 , 因此 需要 数据 库 专 家 绞 尽 脑 汁 , 考虑 文件 采用 何 种 形式 和 
如 何 分 布 ， 但 效果 往往 不 佳 。 而 ASM 的 出 现 ， 大 大 降低 了 数据 库 规划 的 复杂 性 ， 而 且 能 取得 较 
好 的 效果 。 因 此 ， 认 为 ASM 技术 是 Oracle 发 展 历史 上 的 一 个 里 程 碑 ， 并 不 为 过 。 

我 们 知道 ,在 ASM 出 现 以 前 , 数据库 文 件 从 形式 上 可 划分 为 普通 文件 和 裸 设备 。 普 通 文件 是 
存在 于 文件 系统 中 的 文件 ， 当 然 , 文件 系统 可 以 有 多 种 ， 比 如 AIX 中 的 JES2、LINUX 中 的 EXT3, 
WINDOWS 中 的 NTFS， 还 有 网 络 文件 系统 NES 等 。 它 们 尽管 各 有 差异 ， 但 是 访问 接口 类 似 ， 都 
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是 以 目录 树 的 形式 组 织 的 ， 可 以 通过 简单 的 命令 实现 创建 、 移 动 或 删除 操作 ， 使 用 起 来 较为 简单 ， 
但 因为 增加 了 额外 的 文件 系统 开销 , 所 以 性 能 一 般 。 而 裸 设备 是 指 , 操作 系统 上 的 一 个 磁盘 设备 或 
逻辑 卷 以 字符 设备 的 形式 存在 并 提供 直接 访问 。 由 于 对 裸 设备 的 访问 是 直接 的 , 不 需要 任何 额外 的 
开销 ， 因 此 其 性 能 比 文件 的 访问 好 一 些 ， 大 概 可 以 提升 8% 左 右 ， 当 然 这 只 是 一 些 内 部 测试 数据 ， 
并 不 总 是 成 立 。 裸 设备 的 不 足 之 处 也 是 显而易见 的 , 就 是 难于 管理 , 而且 很 不 灵活 , 需要 事先 创建 
好 各 个 裸 设备 ,如 果 在 一 台 服 务 器 上 存在 多 个 数据 库 , 还 容易 误 用 。 鉴 于 10g 版 本 以 前 的 数据 库 文 
件 管 理 和 使 用 存在 这 样 或 那样 的 缺陷 ,Oracle 在 推出 10g 版 本 时 带 来 了 革命 性 的 技术 一 一 ASM。 Ë 
先 ，ASM 解决 了 裸 设备 难于 使 用 的 问题 ， 我 们 只 需要 将 用 于 数据 库 文件 的 磁盘 设备 或 逻辑 卷 放 入 
磁盘 组 (disk group) 中 即 可 ， 在 需要 创建 数据 库 文件 时 ， 只 需 指 定 文件 所 在 的 磁盘 组 ，ASM 将 自 
动 在 磁盘 组 中 创建 数据 库 文件 ， 这 大 大 简化 了 数据 库 文件 的 管理 。 其 次 ，ASM 较 好 地 解决 了 数据 
库 文 件 访问 的 性 能 问题 ， 这 得 益 于 ASM 的 SAME 特性 ，SAME 是 Stripe And Mirror Everything 的 缩 
写 ， 即 条 带 化 并 镜像 一 切 。 也 就 是 说 ， 在 磁盘 组 中 创建 数据 库 文件 时 ，ASM 会 对 文件 进行 条 带 化 
处 理 , 按照 文件 的 类 型 ， 选取 合适 的 条 带 值 , 将 文件 分 布 在 所 有 的 磁盘 上 ，, 这样 就 很 好 地 避免 了 因 
某 些 磁盘 访问 过 于 频繁 而 造成 IO 性 能 下 降 的 问题 。 最 后 ，ASM 提供 了 更 好 的 容错 性 ， 避 免 单 点 
失败 导致 数据 丢失 的 情况 出 现 。 这 是 因为 ASM 在 磁盘 组 中 设置 了 不 同 的 失败 组 ， 每 个 文件 根据 文 
件 类 型 和 宛 余 度 的 设置 , 其 内 容 可 以 在 不 同 的 失败 组 中 存在 一 个 或 多 个 副本 (mirror), 这 样 , 即使 
某 个 磁盘 出 现 问 题 导致 文件 的 部 分 内 容 不 能 被 正常 访问 ，ASM 也 能 自动 从 其 他 失败 组 上 访问 该 文 
件 的 镜像 内 容 。 这 里 以 表格 的 形式 对 三 者 进行 比较 ， 具 体内 容 如 表 8-1 所 示 。 


表 8-1 
文件 系统 R 设 备 ASM 
易 用 性 好 差 好 
性 能 一 般 较 好 好 
容错 性 差 差 好 
RAC 支 持 差 一 般 Af 


另外 ，ASM 还 具有 强大 的 存储 能 力 ， 可 以 达到 : 
口 63 磁盘 组 ; 
口 10 000 磁盘 ; 
口 4PB/ 磁 盘 ; 
口 40EB 总 容量 ; 
口 1 000 000 文件 /磁盘 组 ; 
口 2.4TB/ 文 件 ， 而 11g 版 本 更 扩展 到 了 128TB 。 
综 上 所 述 ，ASM 是 目前 最 好 的 Oracle 数据 库存 储 技术 。 当 然 ， 和 任何 新 生 技术 一 样 ，ASM 
刚 推 出 时 ， 由 于 存在 较 多 的 Bug， 有 时 会 导致 元 数据 出 错 而 造成 数据 库 不 能 访问 ， 严重 时 甚至 造 
成 数据 库 损坏 。 另 外 ， 由 于 Oracle 提供 的 asmemd 工具 功能 有 限 ， 和 外 部 的 文件 系统 进行 文件 交 
换 很 不 方便 ， 因 此 ，Oracle 10g 的 用 户 对 ASM 的 接受 程度 比较 低 ， 都 不 想 当 “ 先 驱 ”。 但 随 着 技 
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术 的 不 断 完善 ,到 11g 版 本 时 ，ASM 技术 已 比较 成 熟 , 不 但 变 得 更 为 健壮 ， 而 且 asmemd 工具 的 
功能 有 了 大 幅 提 升 ， 还 提供 了 和 文件 系统 类 似 的 命令 语法 。 


ASM 和 ASMLIB 
ASM 的 存储 结构 如 图 8-1 所 示 。 


А$М ЗЯ 
Y 
ASM EUH. 


ASM 文 件 


图 8-1 


ASM 的 管理 单位 是 磁盘 组 ， 类 似 操 作 系统 的 卷 组 ， 每 个 磁盘 组 由 多 个 磁盘 构成 ， 类 似 构 成 
卷 组 的 物理 卷 ，ASM 磁盘 可 以 使 用 以 下 存储 资源 : 

а 整个 磁盘 或 磁盘 分 区 ; 
a 存储 阵列 上 划分 的 逻辑 单元 (LUN ); 
о 逻辑 卷 ; 
о 网 络 文 件 系 统 ( NFS )。 

这 些 磁盘 可 以 组 织 成 多 个 失败 组 ， 顾 名 思 义 ， 失 败 组 的 主要 目的 是 为 了 容错 ， 因 为 ASM 的 
SAME 特性 ，ASM 文件 的 扩展 可 以 存在 一 个 或 多 个 镜像 ， 每 个 镜像 放 在 不 同 的 失败 组 ， 这 样 即 
使 某 个 失败 组 上 的 磁盘 无 法 访问 ，ASM 也 可 以 通过 访问 位 于 其 他 失败 组 的 镜像 加 以 恢复 。 磁 盘 
组 在 逻辑 上 组 织 成 一 个 大 的 文件 系统 ,以 ASM 文件 的 方式 管理 上 面 的 内 容 ,， ASM 文件 类 似 普通 
的 操作 系统 文件 ， 也 有 目录 名 和 INODE ( 主要 保存 扩展 分 配 表 和 文件 属性 )。 

ASM 文件 由 扩展 组 成 ， 扩 展 是 一 组 连续 的 分 配 单元 ， 扩 展 的 大 小 一 般 为 1 个 分 配 单位 ,但 
是 对 于 大 型 文件 ,就 需要 很 大 的 分 配 表 ， 这 些 分 配 表 在 文件 打开 时 被 放 在 数据 库 的 共享 池 中 , 会 
消耗 很 多 内 存 ， 因 此 ， 为 了 支持 VLDB ，ASM 采用 了 多 种 大 小 的 扩展 ， 对 于 超过 20 000 个 扩展 
的 文件 , 超出 部 分 将 采用 4 个 分 配 单位 的 扩展 , 对 于 超过 40 000 个 扩展 的 文件 , 超出 部 分 将 采用 
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16 个 分 配 单位 的 扩展 。 

我 们 知道 ，ASM 具有 SAME 特性 ， 而 ASM 文件 镜像 的 单位 是 扩展 ， 在 分 配 表 中 ， 记 录 了 
每 个 镜像 所 处 的 扩展 。 也 就 是 说 ， 假 如 某 个 ASM 文件 存在 一 个 镜像 的 话 ， 在 形式 上 并 不 像 数 据 
库 日 志文 件 的 镜像 那样 存在 两 个 文件 , 还 是 只 有 一 个 文件 ,只 不 过 文件 的 分 配 表 中 记录 了 两 份 保 
存 同样 内 容 的 扩展 ， 这 些 扩 展位 于 不 同 的 失败 组 。 分 配 单元 是 最 小 的 IO 单位 ， 类 似 于 数据 库 的 
块 ， 默 认 是 1 MB ， 最 大 可 设置 到 64 МВ. ASM 在 进行 条 带 化 时 ， 一 般 也 是 以 分 配 单元 为 单位 进 
行 分 割 的 。 每 个 分 配 单 元 在 物理 上 由 一 组 连续 的 磁盘 块 构成 。 

对 于 使 用 ASM 存储 数据 的 数据 库 而 言 ， 数 据 库 的 数据 文件 、 重 做 日 志 、 归 档 日 志 等 文件 都 
能 以 ASM 文件 的 形式 存储 在 ASM 磁盘 组 中 ,并且 可 以 存放 在 不 同 的 磁盘 组 中 。 而 到 了 Oracle 11g 
版 本 ， 连 OCR 和 Voting 文件 都 可 以 保存 在 磁盘 组 中 。 

像 数据 库 一 样 ，ASM 也 是 以 实例 的 形式 存在 ， 对 ASM 存储 进行 管理 ， 并 向 ASM 的 使 用 者 
提供 服务 。ASM 实例 结构 如 图 8-2 所 示 。 


结 点 磁盘 组 服务 磁盘 组 服务 Á 
tom=tasm1 tom=tasm2 г 
dick=+asm1 dick=+asm2 数据 库 实例 
SID-salel harry=tasm1 harry=+asm2 SID-sale2 
М 


ASM 
实例 
SID=+asm2 


数据 库 实 例 数据 库 实 例 
SID-testl SID-test2 


ASM 了 磁盘 ASMT TE: 


ASM 磁 盘 组 Tom ASM 磁 盘 组 Dick ASM 磁 盘 组 Harry 


图 8-2 
上 图 列 出 了 ASM 实例 的 一 些 特 有 的 后 台 进 程 ， 至 于 一 般 的 后 台 进 程 ， 比 如 SMON, PMON 
等 ， 因 为 其 功能 和 数据 库 实例 的 那些 后 台 进 程 类 似 ， 所 以 这 里 没有 一 一 列 出 。 在 ASM 实例 中 ， 
存在 以 下 几 种 新 的 后 台 进 程 。 
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口 RBAL: 重 平衡 进程 ， 当 有 磁盘 加 入 或 退出 时 ， 对 ASM 文件 的 扩展 重新 分 布 ， 以 达到 平 
衔 磁盘 访问 的 效果 。 
口 ARBx: 平衡 子 进程 ， 具 体 实 施 平衡 操作 的 一 组 子 进程 。 
在 数据 库 实例 中 ， 存 在 以 下 几 种 新 的 后 台 进 程 。 
口 ASMB: 从 CSS 处 获取 ASM 实例 连接 串 ， 然 后 创建 到 ASM 实例 的 连接 , 和 ASM 进行 交 
互 ， 比 如 更 新 统计 信息 ， 获 取 文 件 扩展 分 配 表 等 。 
口 RBAL: 全 局 性 地 打开 ASM 磁盘 组 中 的 所 有 磁盘 ， 供 后 面 的 操作 使 用 。 
О O0nn: 一 组 连接 到 ASM 实例 的 子 进程 ， 构 成 连接 池 ， 加 快 和 ASM 实例 的 交互 。 

需要 注意 的 是 , ASM 只 是 向 数据 库 提 供 了 ASM 文件 的 空间 分 配 和 文件 管理 服务 , 并 不 接管 
文件 的 读 写 功 能 ， 因 此 ,具体 的 文件 读 写 还 是 由 数据 库 进程 执行 的 。 比 如 ， 数 据 脏 块 的 写 操作 由 
dbwr 进程 完成 ,日志 记录 的 写 操 作 由 lewr 进程 完成 ,归档 日 志 的 写 操 作 由 archive 或 服务 需 进 程 
完成 。 

ASMLIB 是 Oracle 公司 提出 的 一 个 供 ASM 使 用 的 API 规范 和 接口 库 ， 它 主要 包括 磁盘 管理 
和 识别 、 磁 盘 访 问 、 性 能 和 可 靠 性 优化 等 功能 。 如 果 没 有 ASMLIB ASM 需要 使 用 操作 系统 底 
层 的 系统 调用 访问 磁盘 ， 这样 ,对 于 不 同 的 操作 系统 和 存储 ,存在 着 不 一 致 的 访问 方式 ,并且 不 
能 充分 发 挥 存储 硬件 的 能 力 。 因 此 ，Oracle 推出 了 一 套 规范 和 接口 ,命名 为 ASMLIB, ， 向 所 有 操 
作 系 统 和 存储 厂家 开放 , 希望 他 们 能 提供 具体 的 实现 库 , 但 好 像 响应 的 并 不 多 。 目前 , 除了 Oracle 
自己 在 Linux 平 台 推 出 的 参考 实现 外 ， 我 们 还 没有 安装 过 其 他 厂家 实现 的 ASMLIB 。 


8.2 ASM 的 结构 


ASM 的 METADATA 是 由 一 系列 内 部 文件 组 成 的 ， 其 中 FILE 0 就 是 ASM DISKHEADER。 
本 节 将 从 FILE JF, 逐步 介绍 ASM 的 各 类 文件 的 数据 结构 ,通过 本 节 内 容 的 学 习 ， 有 兴趣 的 
朋友 可 以 编写 一 个 自己 的 ASM 数据 分 析 和 数据 抽取 工具 ， 以 便 在 ASM 故障 时 使 用 这 个 工具 进 
行 数据 抽取 。 当 然 也 可 以 直接 使 用 Oracle 的 AMDU 工具 ,不 过 有 些 时 候 ，AMDU 对 数据 一 致 性 
的 要 求 太 高 ， 如 果 AMDU 拒绝 为 你 “ 干 活 ”， 那 么 就 只 能 使 用 自己 编写 的 工具 了 。 


8.2.1 ASM DISKHEADER 的 结构 


ASM 通过 一 系列 元 数据 进行 管理 ， 这 些 元 数据 类 似 于 数据 库 的 数据 字典 。 元 数据 从 形式 上 
分 为 物理 元 数据 和 虚拟 元 数据 。 所 谓 物理 元 数据 , 是 指 记 录 在 磁盘 固定 位 置 的 数据 ， 主 要 包括 磁 
盘 头 、 分 配 表 、 空 闲 空间 表 和 伙伴 状态 表 。 而 虚拟 元 数据 是 指 以 文件 的 形式 存在 的 元 数据 ， 其 位 
置 不 固定， 主要 包括 文件 目录 、 磁 盘 目 录 、 活 动 变化 目录 、 继 续 操 作 目 录 、 模 板 目录 、 别 名 目录 、 
属性 目录 、 过 期 目录 、 注 册 表 等 。 元 数据 的 每 个 块 为 4096B， 每 个 块 都 有 相应 的 结构 ， 这 些 结构 
随 版 本 的 升级 会 略 有 扩展 ， 以 下 介绍 的 数据 结构 是 基于 Oracle 10g R2 版 本 的 。 在 所 有 的 元 数据 
中 ,磁盘 头 信息 都 是 元 数据 的 起 点 ， 通 过 它 的 引导 ,可 以 一 步 步 地 遍历 所 有 的 元 数据 。 磁 盘 头 的 
数据 结构 由 两 部 分 组 成 ， 第 一 部 分 是 块头 ， 共 32 B， 块 头 结构 kfbh 如 下 : 
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typedef struct kfbh í 


ubl endian kfbh; 
ubl hard kfbh; 
kfbtyp type kfbh; 
ubl datfmt kfbh; 
kf bl block kfbh; 
ub4 check kfbh; 
kfcn fcn kfbh; 
ub4 sparel kfbh; 
ub4 spare2 kfbh; 
) kfbh; 


kfbh 中 的 一 些 主要 的 字段 如 下 所 示 。 


名 目录 和 12 种 间接 扩展 。 


О block kfbh: 当前 块 的 位 置信 


О endian kfbh: 平台 软件 的 字 节 顺序 (大 小 端 )。 
口 hard_kfbh: 用 于 标识 的 MAGIC Ж, 
О type kfbh: 元 数据 块 类 型 ， 主 要 包括 1 种 磁盘 头 、4 种 文件 目录 、6 种 磁盘 目录 、11 种 别 


口 datfmt kfbh: 元 数据 块 数据 格式 。 


息 ， 包 括 所 属 对 象 及 块 号 。 


О check_kfbh: 用 于 块 一 致 性 检查 的 校 验 和 。 
О fcn_kfbh: 最 后 一 次 改变 的 改变 号 ， 类 似 于 SCN。 


块头 是 最 基本 的 ， 每 个 元 数据 块 都 会 包含 块头 。 人 磁盘 头 的 第 二 部 分 结构 kfdhdb 包含 了 主要 


的 磁盘 信息 ， 定 义 如 下 : 


typedef struct kfdhdb { 


kfddrb driver kfdhdb; 

ub4 compat kfdhdb; 

ub2 dsknum kf dhdb; 
kfdgtp grptyp kfdhdb; 
kfdhdr hdrsts kfdhdb; 
oratext dskname kfdhdb[32]; 
oratext grpname kfdhdb[32]; 
oratext fgname kfdhdb[32]; 
oratext capname kfdhdb[32]; 
kfts crestmp kfdhdb; 
kfts mntstmp kfdhdb; 
ub2 secsize kfdhdb; 
ub2 bl ksize_kfdhdb; 

ub4 ausize kfdhdb; 

ub4 mfact kfdhdb; 

ub4 dsksize kfdhdb; 

ub4 pmcnt kfdhdb; 

ub4 fstlocn kfdhdb; 
ub4 altlocn kfdhdb; 
ub4 flbllocn_kfdhdb; 
ub2 redomirrors kfdhdb[ 4]; 
ub4 dbcompat kfdhdb; 
kfts grpstmp kfdhdb; 
ub4 ub4spare kfdhdb[58]; 
kfracdb acdb kfdhdb; 


} kfdhdb; 
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其 中 一 些 主要 的 字段 如 下 所 示 。 

口 driver_kfdhdb: 驱动 程序 保留 信息 。 

口 compat_kfdhdb: 打开 本 磁盘 组 所 需 的 ASM 最 小 版 本 。 

О dsknum kfdhdb: 磁盘 号 。 

О grptyp kfdhdb: 磁盘 组 元 余 类 型 ， 包括 外 部 宛 余 、 正 常见 余 和 高 度 见 余 三 种 类 型 。 

口 hdrsts_kfdhdb: 磁盘 头 状态 。 

О dskname kfdhdb: 磁盘 名 。 

О grpname_kfdhdb: 磁盘 组 名 。 

口 fgname kfdhdb: 失败 组 名 。 

口 crestmp_kfdhdb: 创建 时 间 戳 。 

О mntstmp_kfdhdb: Mount Hj [H] El s 

О secsize kfdhdb: 44394 PX KO] 

О blksize kfdhdb: 元 数据 块 大 小 。 

О ausize_kfdhdb: 分 配 单元 大 小 。 

О dsksize_kfdhdb: 磁盘 大 小 ， 以 分 配 单元 为 单位 。 

口 pmcnt kfdhdb: 物理 元 数据 所 占用 的 分 配 单元 数 。 

口 fstlocn_kfdhdb: 空闲 空间 表 的 第 一 个 块 号 。 

О altlocn_kfdhdb: 分 配 表 的 第 一 个 块 号 。 

О flbllocn_kfdhdb: 文件 目录 指针 , 文件 目录 是 一 个 特殊 的 虚拟 元 数据 文件 , 它 包 含 了 所 有 
ASM 文 件 的 TNODE， 当 然 ， 它 也 包含 自身 的 ITNODE， 其 文件 号 是 1。 如 果 本 磁盘 包含 
了 文件 目录 的 第 一 个 扩展 ， 那 么 就 用 该 字段 指向 其 所 在 的 第 一 个 分 配 单元 号 。 

口 dbcompat kfdhdb: 打开 磁盘 组 所 需 的 数据 库 实 例 最 小 版 本 ， 在 数据 库 实例 初始 化 参数 
compatible 中 设置 了 数据 库 实 例 的 兼容 性 版 本 ， 该 版 本 小 于 或 等 于 数据 库 软 件 的 版 本 ， 比 
如 11е 版 本 的 数据 库 实例 通过 设置 compatible 参数 可 以 运行 在 10.2 的 兼容 性 版 本 下 。 

口 grpstmp_kfdhdb: 磁盘 组 创建 时 间 玲 。 


8.2.2 ASM FILE DIRECTORY 文件 结构 


文件 目录 包含 了 所 有 ASM 文件 的 INODE 信息 ， 其 中 最 主要 的 是 文件 大 小 和 扩展 分 配 表 ， 
其 文件 号 是 1. 文件 目录 在 结构 上 是 按 块 组 织 的 , 每 个 块 的 数据 结构 由 三 部 分 组 成 。 第 一 部 分 是 
块头 kfbh, 结构 和 磁盘 头 的 块头 一 样 ， 第 二 部 分 结构 kfffdb， 主 要 包含 了 文件 分 配 信息 ， 定 义 
如 下 : 


typedef struct kfffdb { 
kffbnd node kfffdb; 
ub4 hibytes kfffdb; 
ub4 lobytes_kfffdb; 
ub4 xtntcnt_kfffdb; 
ub4 xtnteof kfffdb; 
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ub4 blksize_kfffdb; 
kfff df flags_k db; 
ubl filetype kfffdb; 
kfrs dxrs kfffdb; 
kfrs ixrs kfffdb; 
ub4 dxsiz_k db[ 3]; 
ub4 ixsiz k db[3]; 
ub2 xtntblk kfffdb; 
ub2 break_k db; 
ubl prizn k db; 
ubl seczn k db; 
ub2 ub2spare kfffdb; 
ub4 alias k db[2]; 
ubl strpwdth kfffdb; 
ubl strpsz k db; 
ub2 usmsz k db; 
kfts crets k db; 
kfts modts k db; 
ub4 spare k db[16]; 
oratext usm kfffdb[1024]; 
) kfffdb; 


其 中 一 些 主要 的 字段 如 下 所 示 。 
口 node kfffdb: 块 的 分 配 信息 ， 包 括 块 的 分 支 号 和 指向 freelist 中 下 一 个 块 的 指针 ， 分 支 号 
是 一 个 内 部 序列 号 ， 每 次 块 被 重用 都 会 增加 ， 其 作用 类 似 于 版 本 号 。 
о hibytes kfffdb: 文件 字 节 数 (高 位 )。 
О lobytes_kfffdb: 文件 字 节 数 ( 低位 )。 
O xtntcnt_kfffdb: 直接 扩展 数 。 
口 xtnteof_kfffdb: 文件 EOF 之 前 的 扩展 数 。 
О blksize_kfffdb: 每 个 块 的 字 节 数 , 不 同 的 文件 类 型 块 大 小 可 能 不 同 ， 比 如 , 元 数据 文件 为 
4096 B， 数 据 库 日 志文 件 为 512 B， 而 数据 文件 一 般 是 8192 В. 
О flags_kfffdb: 文件 标志 。 
О filetype_kfffdb: 文件 类 型 ， 主 要 包括 以 下 几 种 。 
m 15: 元 数据 文件 ; 
12: 数据 文件 ; 
13: 参数 文件 ; 
3: H 志文 件 ; 
6: 临时 文件 ; 
m 1: 控制 文件 。 
口 dxrs_kfffdb: 直接 扩展 匈 余 模式 ， 如 果 采 用 了 正常 元 余 ， 每 个 扩展 还 会 增加 一 个 镜像 ， 而 
如 果 采 用 高 度 宛 余 ， 每 个 扩展 会 增加 两 个 镜像 。 
O ixrs kfffdb: 间接 扩展 宛 余 模式 。 
口 dxsiz_kfffdb: 每 种 扩展 大 小 包含 的 直接 扩展 数 ,扩展 大 小 分 为 1 个 分 配 单元 、4 个 分 配 单 
Jú, 16 个 分 配 单元 三 种 。 
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口 prizn_kfffdb: 主 扩展 所 处 磁盘 区 。 
О seczn kfffdb: 镜像 扩展 所 处 磁盘 区 。 
D alias kfffdb: 文件 别名 指针 。 


O ixsiz_kfffdb: 每 种 扩展 大 小 包含 的 间接 扩展 数 。 
О xtntblk_kfffdb: 本 块 包含 的 直接 和 间接 扩展 指针 数 。 
О break_kfffdb: 直接 和 间接 扩展 指针 的 边界 插 槽 , 一 般 是 60, 表示 前 60 个 是 直接 扩展 指针 。 


口 strpwdth_kfffdb : 条 带宽 度 , 即 条 带 跨越 几 个 扩展 , 可 以 简单 理解 为 在 几 个 磁盘 间 做 条 带 。 
О strpsz_kfffdb: 条 带 大 小 (2^N )， 比 如 ，20 表示 1 MB 的 条 带 ，17 表示 128 KB 的 条 带 。 


条 带宽 度 和 条 带 大 小 决定 了 条 带 划 分 模式 ， 效 果 如 图 8-3 所 示 。 


ASM 文 件 : Bl | B2 | B3 | B4 | B5 | B6 | B7 | B8 Block-128K Ef 

扩展 0 扩展 1 扩展 2 

Bl | 128K 条 带 B B3 

B4 B5 B6 

B7 B8 
扩展 : IM 75 

ES i ) 
Y 
条 带宽 度 ，3 
图 8-3 


从 上 图 可 以 看 出 ，1 MB 的 文件 在 做 细 粒 度 的 条 带 (128 КВ) 时 需要 3 个 扩展 ， 如 果 做 粗 粒 


度 的 条 带 (1 MB )， 则 只 需要 1 个 扩展 。 

C) usmsz kfffdb: 文件 附加 的 用 户 元 数据 大 小 
O crets_kfffdb: 文件 创建 时 间 。 

口 modts_kfffdb: 文件 修改 时 间 。 

О usm kfffdb: 文件 附加 的 用 户 元 数据 。 


ypedef struct kfxp { 


ub4 au_kfxp; 
ub2 disk_kfxp; 
kf xpf flags kfxp; 
ubl chk kfxp; 


° 


文件 目录 块 的 第 三 部 分 是 一 个 数组 结构 kfxp[360], 最 多 可 以 包含 360 个 扩展 指针 , 定义 如 下 : 
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其 中 一 些 主要 的 字段 如 下 所 示 。 
О au kfxp: 扩展 的 第 一 个 分 配 单元 号 。 
О disk_kfxp: 所 属 磁盘 号 。 
口 flags kfxp: 标志 。 
口 chk_kfxp: 用 于 一 致 性 检查 的 校 验 和 。 
在 扩展 分 配 表 中 , 扩展 分 为 直接 扩展 和 间接 扩展 ， 直 接 扩展 中 存放 的 是 实际 的 文件 内 容 ， 而 
间接 扩展 中 存放 的 是 第 二 层 的 扩展 分 配 表 , 通过 引入 间接 扩展 , 可 以 更 灵活 地 表达 超大 型 文件 的 
存放 位 置 。 扩 展 分 配 表 结构 如 图 8-4 所 示 。 


间接 扩 


[Н] ЖУЛ 


文件 分 配 表 
图 8-4 
对 于 间接 扩展 , 每 一 个 扩展 块 的 结构 也 由 三 部 分 组 成 。 第 一 部 分 是 块头 ktbh,， 第 二 部 分 结构 


kffixb 主要 包含 了 文件 分 配 信息 ， 定 义 如 下 : 
typedef struct kffixb { 
ub4 dxsn kffixb; 
ub2 xtntblk kffixb; 
kfrs dXrs kffixb; 
ubl ublspare kffixb; 
ub4 ub4spare kffixb; 
) kffixb; 


其 中 一 些 主要 的 字段 如 下 所 示 。 

口 dxsn_kffixb: 第 一 个 扩展 号 。 

О xtntblk_kffixb: 块 中 的 扩展 指针 数 。 

О dXrs_kffixb: 扩展 元 余 模式 。 

第 三 部 分 是 一 个 数组 结构 kfxp[480]， 最 多 可 以 包含 480 个 直接 扩展 指针 。 
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8.2.3 ASM ALIAS DIRECTORY 文件 结构 


别名 目录 记录 磁盘 组 中 的 别名 信息 ,别名 可 以 对 应 具体 的 文件 , 也 可 以 是 某 个 中 间 路 径 ， 其 
作用 类 似 于 文件 系统 的 目录 ,并 且 也 采用 了 层次 性 的 形式 来 表示 ， 其 文件 号 是 6。 别名 目录 在 结 
构 上 是 按 块 组 织 的 , 每 个 块 的 数据 结构 由 三 部 分 组 成 , 第 一 部 分 是 块头 kftbh， 其 结构 和 磁盘 头 的 
块头 一 样 ; 第 二 部 分 是 kffdnd， 主 要 用 来 定位 ， 它 描述 了 块 在 目录 树 中 的 位 置 ; 第 三 部 分 结构 是 
一 个 数组 ， 包 含 了 在 目录 树 中 处 于 同一 层 的 别名 信息 ， 每 个 目录 项 ( 别名 ) 的 结构 为 kfade。 在 
描述 具体 的 数据 结构 前 ， 我 们 可 以 先 用 图 8-5 表示 目录 树 的 整体 结构 。 


定位 


磁盘 组 根 目标 : +DG/ | < 不 存在 > 


IRE 
IRSE 


INE 


图 8-5 


接 下 来 ,我 们 具体 看 一 下 用 于 定位 的 kffdnd: 
typedef struct kffdnd { 


kffbnd bnode kffdnd; 

kffban overfl kffdnd; 

kffban parent kffdnd; 

kffban fstblk kffdnd 
) kffdnd; 


其 中 一 些 主要 的 字段 如 下 所 示 。 

О bnode_kffdnd: 块 的 分 配 信 息 ， 包 括 块 的 分 支 号 和 指向 freelist 中 下 一 个 块 的 指针 。 
О overfl kffdnd: 指向 同一 层次 的 下 一 个 块 ， 即 兄弟 块 。 

口 parent_kffdnd : 指 癌 上 一 层 的 块 ， 即 父 块 。 

о fstblk_kffdnd: 指向 同一 层次 的 第 一 个 块 。 

别名 kfade 的 定义 如 下 : 


208 第 8 章 理解 ASM 的 结构 


typedef struct kfade { 


kffden 
oratext 
ub4 
ub4 
kf adef 
ubl 
ub2 

} kfade; 


entry_kfade; 


name kfade[48]; 


fnum kfade; 
finc kfade; 
flags kfade; 


ublspare kfade; 
ub2spare kfade; 


其 中 一 些 主要 的 字段 如 下 所 示 。 


子 块 。 


口 name_kfade: 名 称 。 

О fnum_kfade; 对 应 文件 号 ， 如 果 别 名 对 应 的 是 目录 ， 该 字段 无 用 。 

О finc kfade: 文件 分 文 号 ， 文 件 号 被 复 用 时 ， 会 和 月 动 增加 分 支 号 以 示 区 别 。 

口 flags_kfade: 标志 ， 可 以 区 分 别名 对 应 的 是 文件 还 是 目录 。 

此 处 以 文件 1DG/orayinitspfile 为 例 ， 来 分 析 ASM 怎样 在 别名 目录 中 找到 相应 的 别名 。 


口 entry_kfade: 每 个 表 项 的 通用 头 结构 ,包括 分 支 号 、HASH 值 和 指向 下 一 层 块 的 指针 ， 即 


(1) «DG 根 路 径 表 示 文 件 位 于 DG 磁盘 组 。 

(2) 从 别名 目录 的 第 一 个 块 开始 , 扫描 其 中 的 别名 数组 寻找 ora 别名 ， 如 果 未 找到 , 根据 块 的 
kffdnd 结构 中 的 overfl_kffdnd 指针 找到 兄弟 块 ， 接 着 扫描 ， 直 到 找到 为 止 。 

(3) 根据 ora 别名 结构 中 的 entry_kfade 指针 找到 下 一 层 路 径 的 块 ， 寻 找 init 别名 。 

(4) 根据 init 别名 结构 中 的 entry_kfade 指针 找到 下 一 层 路 径 的 块 ， 找到 spfile 别名 , 至 此 , 搜 


寻 结 束 。 


E ASM 中 ， 别 名 默认 由 系统 自动 生成 ， 根 据 文件 类 型 ,系统 在 合适 的 目录 层次 中 为 文件 产 


生 别 名 ， 其 形式 为 : 


+< 人 磁盘 组 >/< 数 据 库 名 >/< 分 类 >/< 标 记 >.< 文 件 号 >.< 文 件 分 支 > 
具体 的 产生 规则 如 表 8-2 所 示 。 


表 8-2 

Oracle 文 件 类 型 分 类 ж № 默认 模板 
控制 文件 controlfile CF/BCF CONTROLFILE 
数据 文件 datafile < 表 空 间 名 >_< 文 件 号 > DATAFILE 
在 线 日 志 online_log log < 线索 号 > ONLINELOG 
归档 日 志 archive_log parameter ARCHIVELOG 
临时 文件 temp < 表 空 间 名 >_< 文 件 号 > TEMPFILE 
数据 文件 备份 分 片 backupset 客户 端 指定 BACKUPSET 
数据 文件 增 量 备份 分 片 backupset 客户 端 指定 BACKUPSET 
归档 日 志 备份 分 片 backupset 客户 端 指定 BACKUPSET 
数据 文件 拷贝 datafile < 表 空 间 名 >_< 文 件 号 > DATAFILE 
初始 化 参数 文件 init Spfile PARAMETERFILE 
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CE) 
Oracle 文 件 类 型 分 类 ж dc 默认 模板 
DG Broker 配 置 文件 Drc drc DATAGUARDCONFIG 
闪 回 日 志文 件 rlog < 线索 号 > < 日 志 号 > FLASHBACK 
备份 后 块 改变 跟踪 位 图 CTB BITMAP CHANGETRACKING 
控制 文件 自动 备份 AutoBackup 客户 端 指定 AUTOBACKUP 
数据 泵 导出 文件 Dumpset Dump DUMPSET 
AE G BEE XTRANSPORT 
OCR 文件 ocrfile OCRFILE 


当然 , 别名 也 可 以 在 文件 创建 时 显 式 指定 别名 , 这 时 需要 提供 完整 的 路 径 名 , 从 磁盘 组 开始 ， 
中 间 的 目录 必须 是 已 经 存在 的 ， 如 果 不 存 在 的 话 ， 要 先 手工 创建 这 些 目录 。 


8.2.4 ASM DISK DIRECTORY 文件 结构 


磁盘 目录 记录 磁盘 组 中 所 有 磁盘 的 信息 ， 其 文件 号 是 2。 磁 盘 目 录 在 结构 上 是 按 块 组 织 的 ， 
和 别名 目录 的 组 织 形式 相同 ,每 个 块 的 数据 结构 也 由 三 部 分 组 成 , 第 一 部 分 是 块头 kfoh, 其 结构 


和 别名 目录 的 块头 是 一 样 的 ; 第 二 部 分 的 结构 和 别名 目录 的 kffdnd 结构 也 是 一 样 的 ; 第 三 部 分 是 


一 个 数组 ， 数 组 的 每 一 项 都 包含 了 一 个 磁盘 的 信息 ， 


typedef struct kfddde { 


kffden entry kfddde; 
ub2 dsknum kf ddde; 
kfdsta state kfddde; 
ubl ublspare kfddde; 
oratext dskname kf ddde[32]; 
oratext fgname kfddde[32]; 
kfts crestmp kfddde; 
kfts failstmp kfddde; 
ub4 ti mer kfddde; 
ub4 size kfddde; 
ub4 spare kfddde[5]; 
kfdzon zones kfddde[4]; 

) kfddde; 


其 中 一 些 主要 的 字段 如 下 所 示 。 


О dsknum_kfddde: 磁盘 号 。 

О state kfddde: 磁盘 状态 。 

О dskname kfddde: 磁盘 名 。 

口 fgname_kfddde: 失败 组 名 。 

O crestmp_kfddde: £m [B] £i s 
O failstmp kfddde: ЖЕКЕН] o 


其 结构 kfddde 定义 如 下 : 


O entry_kfddde: 每 个 表 项 的 通用 头 结构 ， 包 括 分 文 号 、 散 列 值 、 指 向 下 一 层 块 的 指针 。 
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O timer kfddde: 失败 定时 需 。 

О size_kfddde: 分 配 单元 数 。 

О zones_kfddde: 整个 磁盘 按照 冷 热 程度 被 划分 为 四 个 区 ， 该 数组 存放 每 个 区 的 布局 及 使 用 
情况 。 


8.2.5 M ASM 存储 结构 谈 ASM 日 常 维护 的 要 点 


通过 前 面 几 节 对 ASM 存储 结构 的 介绍 ， 我 们 可 以 总 结 出 以 下 一 些 有 用 的 经 验 。 
同一 磁盘 组 采用 性 能 接近 的 磁盘 。 鉴 于 ASM 条 带 化 并 且 镜 像 一 切 的 特性 ， 每 个 文件 都 会 分 
布 在 所 有 磁盘 上 ， 因 此 如 果 某 个 硬盘 性 能 较 差 ， 就 会 形成 瓶颈 ， 进 而 影响 整体 的 IO 性 能 。 
а 同一 磁盘 组 采用 大 小 接近 的 磁盘 。ASM 条 带 化 并 且 镜 像 一 切 的 特性 ， 会 把 文件 尽量 平均 
分 布 在 所 有 磁盘 上 ， 因 此 如 果 某 个 便 盘 容量 偏 小 ， 就 有 可 能 发 生 ORA-15041 错误 ( 磁盘 
组 空间 耗 尽 )， 尽 管 这 时 其 他 硬盘 可 能 还 有 空闲 空间 。 
о 失败 组 的 容量 应 该 相同 ,否则 ASM 将 只 会 使 用 最 小 的 那个 失败 组 的 大 小 ,其 他 空间 将 不 
会 被 使 用 ， 从 而 造成 容量 浪费 。 
a 不 同 的 失败 组 在 物理 上 应 相对 隔离 , 比如 , 置 于 不 同 的 磁盘 阵列 , 使 用 不 同 的 HOSTBUS 
ADAPTER 连接 等 ， 防 止 发 生 单 点 故障 。 
口 如 果 存 储 自身 未 实施 硬件 RAID 保护 ， 建 议 采 用 ASM 镜像 进行 元 余 。 
а 磁盘 头 信息 不 要 被 操作 系统 覆盖 。 有 些 操作 系统 会 在 磁盘 头 存放 一 些 控制 信息 ， 这 些 信 
息 有 可 能 会 覆盖 掉 ASM 磁盘 头 信息 ， 因 此 在 实施 ASM 时 ， 需 要 了 解 这 些 情况 ， 并 采取 
相应 措施 来 规避 ， 比 如 ， 可 以 为 磁盘 建 几 个 分 区 ， 使 用 后 面 的 分 区 作为 ASM 磁盘 等 。 
а 将 数据 库 文 件 和 用 于 数据 库 恢 复 的 文件 ( 归档 日 志 、RMAN 备份 等 ) 放 在 不 同 的 磁盘 组 。 
а 需要 扩充 磁盘 时 ， 尽 量 一 次 加 入 多 个 磁盘 。 每 次 加 入 磁盘 时 ，ASM 都 会 进行 重新 平衡 操 
作 ， 把 其 他 磁盘 上 的 一 部 分 扩展 转移 到 新 加 入 的 磁盘 中 ， 这 会 带 来 一 些 开 销 。 因 此 一 次 
加 入 多 个 磁盘 意味 着 减少 重新 平衡 的 次 数 ， 相 应 地 ， 也 就 减少 了 额外 的 开销 。 

О 定期 检查 ASM 实例 和 数据 库 实例 的 ALERT 文件 ， 及 时 解决 出 现 的 磁盘 故障 。 

о 有 些 操 作 系 统 为 同一 个 磁盘 设备 定义 了 几 个 设备 名 ， 每 个 设备 名 使 用 不 同 的 路 径 访 问 同 
一 个 磁盘 ， 这 可 以 增加 UO 吞吐 量 。 但 是 ASM 自身 是 无 法 进行 多 路 径 识 别 的 ， 这 些 不 同 
路 径 会 被 ASM 认为 是 不 同 的 磁盘 , 因此 需要 操作 系统 为 支持 多 路 径 的 设备 提供 伪 设备 名 
供 ASM 使 用 。 

а 直接 使 用 磁盘 或 LUN， 不 需要 使 用 逻辑 卷 。 

О 关注 Oracle 公布 的 ASM 相关 的 Bug， 必 要 时 安装 补丁 包 。 

О 熟悉 相关 的 ASM 工具 ， 这 些 工具 可 能 会 为 你 提供 很 大 的 帮助 ， 推 荐 的 工具 主要 包括 : 

m ASMCMD 实用 命令 行 工 具 ; 

m AMDU 数据 拯救 工具 ; 

m KFED 元 数据 编辑 工具 。 
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8.3 如何 使 用 KFED 分 析 和 修改 ASM 数据 


KFED 是 Oracle 提供 的 检查 、 修 改 ASM 元 数据 的 实用 工具 , 类 似 于 修改 数据 块 的 bbed 工具 。 
KFED 工具 可 以 通过 以 下 途径 获取 : 
口 对 于 UNIX/LINUX 系统 ， 可 通过 make 命令 生成 。 


cd $ORACLE HOME/RDBMS/lib 
make -f ins RDBMS.mk i kfed 


此 时 在 $ORACLE_HOME/bin 目录 下 将 会 生成 KFED 可 执行 程序 。 
口 对 于 Windows 系统 ， 可 从 Metalink 下 载 kfedwin.exe 可 执行 程序 。 
下 面 简单 介绍 KFED 工具 的 一 些 常见 使 用 场景 。 
1. 读 取 ASM 元 数据 信息 
以 下 命令 用 于 读 取 磁盘 头 元 数据 : 


gridglocalhost ~] $ kfed read /dev/oracleasm/disks/ ASMDI SK1 aunum=0 bl knum=0 


[ 

kfbh. endian: 1; 0x000: 0x01 

kfbh. hard: 130 ; 0x001: 0x82 

kfbh.type: 1; 0x002: KFBTYP DISKHEAD 

kfbh.datfmt: 1; 0x003: 0x01 

kf bh. block. bl k: 0; 0x004: T=0 NUMB=0x0 

kf bh. block. obj: 2147483648 ; 0x008: TYPE=0x8 NUMB=0x0 

kf bh. check: 2119965978 ; 0x00c: 0xa5b2eala 

kfbh.fcn.base: 6940 ; 0x010: 0x00001b1lc 

kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 

kfbh.sparel: 0; 0x018: 0x00000000 

kfbh.spare2: 0 ; 0х01с: 0x00000000 

kfdhdb.driver.provstr: ORCLDISKASMDISK1 ; 0x000: length=16 
kfdhdb.driver.reserved[0]: 1145918273 ; 0x008: 0x444d5341 
kfdhdb.driver.reserved[1]: 827020105 ; 0x00c: 0x314b5349 
kfdhdb.driver.reserved[2]: 0 ; 0x010: 0x00000000 
kfdhdb.driver.reserved[3]: 0; 0x014: 0x00000000 
kfdhdb.driver.reserved[4]: 0; 0x018: 0x00000000 
kfdhdb.driver.reserved[5]: 0 ; 0x01c: 0x00000000 

kfdhdb.compat: 186646528 ; 0x020: 0x0b200000 

kfdhdb. dsknum: 0; 0x024: 0x0000 

kfdhdb.grptyp: 2 ; 0x026: KFDGTP NORMAL 

kfdhdb. hdrsts: 3 ; 0x027: KFDHDR MEMBER 

kfdhdb.dskname: DATA 0000 ; 0x028: lengthz9 

kfdhdb.grpname: DATA ; 0x048: length=4 

kfdhdb.fgname: DATA 0000 ; 0x068: lengthz9 

kfdhdb.capname: ; 0x088: lengthz0 

kfdhdb.crestmp.hi: 32958036 ; 0x0a8: HOUR=0x14 DAYS=0x12 MNTH=0x9 YEAR=0x7db 
kfdhdb. crestmp. lo: 1372083200 ; 0x0ac: USEC=0x0 MSEC=0x215 5ЕС5 =0х1с MINS=0x14 
kfdhdb. mntst mp. hi: 32968205 ; 0x0b0: HOUR=0xd DAYS=0x10 MNTH=0x3 YEAR=0x7dc 
kfdhdb. mntstmp. lo: 438844416 ; 0х004: USEC=0x0 MSEC=0x20f SECS=0x22 MI NS=0x6 
kfdhdb. secsize: 512 ; 0x0b8: 0x0200 

kfdhdb.blksize: 4096 ; 0x0ba: 0x1000 

kfdhdb.ausize: 1048576 ; 0x0bc: 0x00100000 

kfdhdb. mfact: 113792 ; 0x0c0: 0x0001bc80 
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dhdb.dsksize: 7640 ; 0x0c4: 0x00001dd8 

dhdb. pment: 2 ; 0x0c8: 0x00000002 

dhdb.fstlocn: 1; 0x0cc: 0x00000001 

dhdb.altlocn: 2; 0x0d0: 0x00000002 

dhdb.flbllocn: 2; 0x0d4: 0x00000002 

dhdb.redomirrors[0]: 0; 0x0d8: 0x0000 

dhdb.redomirrors[1]: 1; 0x0da: 0x0001 

dhdb.redomirrors[2]: 2; 0x0dc: 0x0002 

dhdb.redomirrors[3]: 65535 ; OxOde: Oxffff 

dhdb.dbcompat: 168820736 ; 0x0e0: 0x0a100000 

dhdb. grpstmp. hi: 32958036 ; 0x0e4: HOUR=0x14 DAYS=0x12 MNTH=0x9 YEAR=0x7db 
dhdb.grpstmp.lo: 1371925504 ; 0x0e8: USEC=0x0 MSEC=0x17b SECS=0x1c MI №5 =0х14 
dhdb.vfstart: 0 ; 0x0ec: 0x00000000 

dhdb. vf end: 0 ; 0x0f0: 0x00000000 

dhdb.spfile: 59 ; 0x0f4: 0x0000003b 

dhdb.spfflg: ; 0x0f8: 0x00000001 


dhdb.ub4spare 
dhdb.ub4spare 
dhdb. ub4spare 
dhdb. ub4spare 
dhdb. ub4spare 
dhdb. ub4spare 
dhdb. ub4spare 
dhdb. ub4spare 
dhdb. ub4spare 
dhdb. ub4spare : 
dhdb. ub4spare[ 10 
dhdb.ub4spare[11 
dhdb.ub4spare[12 
dhdb.ub4spare[13 
dhdb.ub4spare[14 
dhdb.ub4spare[15 
dhdb.ub4spare[16 
dhdb.ub4spare[17 
dhdb.ub4spare[18 
dhdb.ub4spare[ 19 
dhdb.ub4spare[20 
dhdb.ub4spare[21 
dhdb.ub4spare[22 
dhdb.ub4spare[23 
dhdb.ub4spare[24 
dhdb.ub4spare[25 
dhdb.ub4spare[26 
dhdb.ub4spare[27 
dhdb.ub4spare[28 
dhdb.ub4spare[29 
dhdb.ub4spare[30 
dhdb.ub4spare[31 
dhdb.ub4spare[ 32 
dhdb.ub4spare[ 33 
dhdb.ub4spare[34 
dhdb.ub4spare[35 
dhdb.ub4spare[36 
dhdb.ub4spare[ 37 


; Ox0fc: 0x00000000 
; 0x100: 0x00000000 
; 0x104: 0x00000000 
; 0x108: 0x00000000 
; 0х10с: 0x00000000 
; 0x110: 0x00000000 
; 0x114: 0x00000000 
; 0x118: 0x00000000 
; Oxllc: 0x00000000 
; 0x120: 0x00000000 
; 0x124: 0x00000000 
; 0x128: 0x00000000 
; 0х12с: 0x00000000 
; 0x130: 0x00000000 
; 0x134: 0x00000000 
; 0x138: 0x00000000 
; 0х13с: 0x00000000 
; 0x140: 0x00000000 
; 0x144: 0x00000000 
; 0x148: 0x00000000 
; 0х14с: 0x00000000 
; 0x150: 0x00000000 
; 0x154: 0x00000000 
; 0x158: 0x00000000 
; 0х15с: 0x00000000 
; 0x160: 0x00000000 
; 0x164: 0x00000000 
; 0x168: 0x00000000 
; 0х16с: 0x00000000 
; 0x170: 0x00000000 
; 0x174: 0x00000000 
; 0x178: 0x00000000 
; Ox17c: 0x00000000 
; 0x180: 0x00000000 
; 0x184: 0x00000000 
; 0x188: 0x00000000 
; 0x18c: 0x00000000 
; 0x190: 0x00000000 
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dhdb.ub4spare[38 
dhdb.ub4spare[39 
dhdb.ub4spare[40 
dhdb.ub4spare[41 
dhdb.ub4spare[42 
dhdb.ub4spare[43 
dhdb.ub4spare[44 
dhdb.ub4spare[45 
dhdb.ub4spare[46 
dhdb.ub4spare[47 
dhdb.ub4spare[48 
dhdb.ub4spare[49 
dhdb.ub4spare[50 
dhdb.ub4spare[51 
dhdb.ub4spare[52 
dhdb.ub4spare[53 
dhdb.acdb.aba.seq 
dhdb.acdb.aba.bl k: 
dhdb.acdb.ents: ; Oxldc: 0x0000 
dhdb.acdb.ub2spare: ; Oxlde: 0x0000 


以 下 命令 用 于 读 取 文 件 目录 元 数据 : aunum 取 自 磁盘 头 的 kfdhdb flbllocn ( 见 上 面 的 输出 小 = 


; 0x194: 0x00000000 
; 0x198: 0x00000000 
; 0х19с: 0x00000000 
; Oxlad: 0x00000000 
; Oxla4: 0x00000000 
; 0x1a8: 0x00000000 
; Oxlac: 0x00000000 
; Ox1b0: 0x00000000 
; 0х104: 0x00000000 
; Ox1b8: 0x00000000 
; Oxlbc: 0x00000000 
; 0х1с0: 0x00000000 
; 0х1с4: 0x00000000 
; 0х1с8: 0x00000000 
; 0х1сс: 0x00000000 
; 0x1d0: 0x00000000 
; Ox1d4: 0x00000000 
; Ox1d8: 0x00000000 


PÇ жж ж >< >Ç PÇ PÇ >Ç >Ç >Ç ж >Ç PÇ >Ç >Ç >Ç >Ç жт > > 
ооо c5 со c5 c5 c5 c5 c5 c5 c5 c5 c c c c c c c 


gridglocalhost ~]$ kfed read FUBHPUERELESSTN dl sKkS/ASMDISKI aunum=2 blknum=1 | more 


[ 

kfbh.endian: ; 0x000: 0x01 

kfbh.hard: 130 ; 0x001: 0x82 

kfbh.type: 4 ; 0x002: KFBTYP FILEDIR 
kfbh.datfmt: 1; 0x003: 0x01 

kf bh. block. bl k: 1; 0x004: T=0 NUMB=0x1 

kf bh. block. obj: 1; 0x008: TYPE=0x0 NUMB=0x1 
kf bh. check: 3975443128 ; 0x00c: Oxecf472b8 
kfbh.fcn.base: 4161 ; 0x010: 0x00001041 
kfbh.fcn.wrap: 0; 0x014: 0x00000000 
kfbh.sparel: 0 ; 0x018: 0x00000000 
kfbh.spare2: 0 ; 0x01c: 0x00000000 

k db.node.incarn: 1; 0x000: A=1 NUMM=0x0 

k db.node.frlist.number: 4294967295 ; 0x004: Oxffffffff 

k db.node.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0 

k db.hibytes: 0 ; 0x00c: 0x00000000 

k db.lobytes: 2097152 ; 0x010: 0x00200000 

k db.xtntcnt: 6 ; 0x014: 0x00000006 

k db.xtnteof: 6 ; 0x018: 0x00000006 

k db. bl kSize: 4096 ; 0х01с: 0x00001000 

k db.flags: 1; 0x020: 021 S=0 5=0 D=0 C=0 |=0 R=0 A=0 
k db.fileType: 15 ; 0x021: 0x0f 

k db.dXrs: 19 ; 0x022: ЅСНЕ=0х1 NUMB=0x3 
k db.iXrs: 19 ; 0x023: 5СНЕ=0х1 NUMB=0x3 
k db.dXsiz[0]: 4294967295 ; 0x024: Oxffffffff 

k db. dXsiz[1]: 0 ; 0x028: 0x00000000 

k db.dXsiz[2]: 0 ; 0x02c: 0x00000000 

k db.iXsiz[0]: 4294967295 ; 0x030: Oxffffffff 

k db.iXsiz[I1]: 0 ; 0x034: 0x00000000 

k db.iXsiz[2]: 0 ; 0x038: 0x00000000 

k db.xtntbl k: 6 ; 0x03c: 0x0006 
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0x050: 
0x054: 
0x058: 
0x05c: 
0 . 


©5 — — со со со о о © со со о о о сос о о © © © © © 


о + ~ ~ 
Ф кә со ro кә ҥка c c n c c oro 


c r 
Ф c со — 


0x03e: 
0x040: 
0x041: 
0x042: 
0x044: 
0x048: 
0x04c: 
0x04d: 
0x04e: 
HOUR=0x14 DAYS=0x12 MNTH=0x9 YEAR=0x7db 
USEC=0x0 MSEC=0x28b 5ЕС5 =0х1с MINS=0x14 
HOUR=0x14 DAYS=0x12 MNTH=0x9 YEAR=0x7db 
USEC=0x0 MSEC=0x28b 5ЕС5 =0х1с MINS=0x14 
0x060: 
0x061: 
0x062: 
0x063: 
0x064: 
0x065: 
0x066: 
0x068: 
0x06a: 
0x06c: 
0x06e: 
0x070: 
0x074: 
0x078: 
0x07c: 
0x080: 
0x084: 
0x088: 
0x08c: 
0x090: 
0x094: 
0x098: 
0x09c: 
0х0а0: 
0x4a0: 
0x4a4: 
0x4a6: 
0х4а7: 
0x4a8: 
Ox4ac: 
Ox4ae: 
Ox4af 
0x4b0: 
0х464: 
0х466: 
0x4b7: 
0х408: 
Ox4bc: 
Ox4be: 
Ox4bf 
0х4с0: 


0х003с 
KFDZN_COLD 
KFDZN_COLD 
0x0000 
Oxffffffff 
Oxffffffff 
0x00 

0x00 
0x0000 


0x00 

0x00 

0x00 

0x00 

0x00 

0x00 
0x0000 
0x0000 
0x0000 
0x0000 
0x0000 
0x00000000 
0x00000000 
0x00000000 
0x00000000 
0x00000000 
0x00000000 
0x00000000 
0x00000000 
0x00000000 
0x00000000 
0x00000000 
0x00000000 
engt h=0 
0x00000002 
0x0000 

L=0 E=0 D=0 S=0 
0x28 
0x00000002 
0x0001 

L=0 E=0 D=0 S=0 
0x29 
0x00000002 
0x0002 

L=0 E=0 D=0 S=0 
0x2a 
0x0000003c 
0x0001 

L=0 E=0 D=0 S=0 
0x17 
0x0000003c 
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~]$ kfed read /dev/oracleasm/disks/ ASMDISK3 aunum=0 bl Кпит=0 


k de[4].xptr.disk: 0 
k de[4].xptr.flags 0 
k de[4].xptr.chk: 22 
k de[5].xptr. au: 3-5 
k de[5].xptr.disk: 2 
k de[5].xptr.flags: 0 
k de[5].xptr.chk: 43 
k de[6].xptr.au: 4294967295 
k de[6].xptr.disk: 65535 
k de[6].xptr.flags: 0 
k de[6].xptr.chk: 42 
k de[359].xptr.au: 4294967295 
k de[359].xptr.disk: 65535 
k de[ 359]. xptr.flags: 0 
k de[359].xptr.chk: 42 
2. 修复 被 覆盖 的 ASM 元 数据 信息 

以 下 命令 用 于 保存 磁盘 头 元 数据 ; 

grid@localhos 

ext=asmdisk3.txt 


gri 


WA >Ç >Ç > > >Ç > > >Ç >< > 
c 
= 


bh. 


d@l оса! hos 


i dgl ocal hos 


.endian: 
.hard: 


.type: 
.datfmt: 


. block. blk: 
block. obj: 


check: 
.fcn. base: 
.fcn.wrap: 
.Sparel: 
spare2: 


以 下 命令 用 于 模拟 磁盘 头 元 数据 被 覆盖 : 
~]$ dd of z/ dev/oracleasm/disks/ ASMDISK3 if=/dev/zero bs=4096 Count =1 
以 下 命令 用 于 验证 磁盘 头 元 数据 是 否 被 损坏 : 


~]$ kfed read ELON ge eg SIN O SES Z aunum=0 bl knum=0 
0x000: 
0x001: 
0x002: 
0x003: 
0x004: 
0x008: 
0x00c: 
0x010: 
0x014: 
0x018: 
0х01с: 


0; 


оо о о о о о о c 


0 


0х4с4: 
0х4с6: 
0х4с7: 
0х4с8: 
Ox4cc: 
Ox4ce: 
Ox4cf 

0x4d0: 
0x4d4: 
0x4d6: 
0x4d7: 


0xf d8: 
0xf dc: 
0xf de: 
0xf df: 


ТЕЕС200 00000000 00000000 00000000 00000000 [ 


Re 


KFED-00322: 


kfb 


gri 
ext 


gri 
ext 


peat 255 ti 


tTraverseB 


dQl оса! hos 
-asmdi sk3. 


d@l оса! hos 
-new.txt 


mes 


0x0000 
L=0 E=0 
0x16 


0x0002 
L=0 E=0 
0x2b 
Oxf ff fff 
Oxf fff 
L=0 E=0 
0x2a 


Oxffffff 
Oxffff 
L=0 E=0 
0x2a 


0x00 
0x00 
KFBTYP | 
0x00 


ock][Invalid OSM block type][][0] 


以 下 命令 用 于 备份 的 文件 恢复 磁盘 头 元 数据 : 


-]$ kfed write /dev/oracleasm/disks/ ASMDI SK3 aunum=0 bl knum=0 


xt 


以 下 命令 用 于 读 取 恢 复 后 的 磁盘 头 元 数据 : 
~]$ kfed read /dev/oracleasm/disks/ ASMDISK3 aunum=0 blknum=0 


D=0 S=0 


0x00000003 


D=0 S=0 


一 


D=0 S=0 


一 


D=0 S=0 


NVALID 


T=0 NUMB=0x0 
TYPE=0x0 NUMB=0x0 
0x00000000 
0x00000000 
0x00000000 
0x00000000 
0x00000000 


Invalid content encountered during block traversal 
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以 下 命令 将 验证 磁盘 头 元 数据 和 用 于 恢复 的 备份 文件 是 否 一 致 : 
[grid@localhost ~] $ diff asmdisk3.txt new.txt 
以 下 命令 用 于 重新 加 载 修 复 后 的 磁盘 : 


[grid@localhost ~]$ sqlplus "las sysasm' 
SQL*Plus: Release 11.2.0.2.0 Production on Sat Apr 7 22:55:02 2012 


Copyright (c) 1982, 2010, Oracle. All rights reserved 


Connected to: 
Oracle Database llg Enterprise Edition Release 11.2.0.2.0 - Production 
With the Automatic Storage Management option 


SQL» alter diskgroup AVM DG mount 


Diskgroup altered. 
以 下 命令 用 于 重新 验证 磁盘 是 否 被 成 功 加 载 : 


[grid@localhost -]$ asmcmd 

ASMCMD> lsdg 

State Type Rebal Sector Block AU Tot al Free Req mir Usable Offline Voting Name 
MB .MB free MB file MB disks files 


MOUNTED EXTERN N 512 4096 1048576 5192 4882 0 4882 0 N AVM_DG/ 
MOUNTED NORMAL N 512 4096 1048576 28646 23277 1414 10931 0 N РАТА! 
MOUNTED EXTERN N 512 4096 1048576 7106 7054 0 1054 0 N FRA DG/ 


3. 修复 部 分 字段 被 损坏 的 ASM 元 数据 信息 

首先 创建 文件 asmdisk3.txt， 插 入 需要 修复 的 磁盘 头 元 数据 的 部 分 字段 ， 比 如 : 
kfbh. hard: 130 ; 0x001: 0x82 

以 下 命令 将 使 用 编辑 的 文件 修复 磁盘 头 元 数据 的 部 分 字段 : 


[gridglocalhost ~] $ kfed merge /dev/oracleasm/disks/ASMDISK3 aunum=0 bl knum=0 
text=asmdisk3.txt 


8.4 如 何 使 用 AMDU 导出 ASM 文件 


AMDU 是 Oracle 11g 引入 的 一 个 新 工具 ， 主 要 用 途 是 从 ASM 磁盘 中 抽取 元 数据 ， 生 成 格式 
化 的 元 数据 块 布局 报告 ， 并 且 可 以 从 磁盘 组 中 抽取 ASM 文件 ， 将 其 写 到 操作 系统 文件 中 。 尽 管 
这 个 工具 是 随 119 版 本 发 布 的 , 但 它 也 支持 ASM 10g, 我 们 可 以 Metalink 下 载 对 应 平台 的 ADMU 
工具 。 

下 面 简单 介绍 AMDU 工具 的 一 些 常见 使 用 场景 。 

1. 生成 元 数据 块 布局 报告 

以 下 命令 用 于 生成 磁盘 组 DATA 的 元 数据 块 布局 报告 ， 这 些 报告 存放 在 AMDU 自动 产生 的 
目录 amdu 2012, 04 07 21 54 22 F: 
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[grid@localhost -]$ amdu -diskstring '/dev/oracleasm/disks/*' -dump 'DATA 
amdu 2012 04 07 21 54 22/ 

AMDU- 00204: Disk N0001 is in currently mounted diskgroup DATA 

AMDU-00201: Disk N0001: '/dev/oracleasm/di sks/ ASMDI SK1' 

AMDU-00204: Disk N0002 is in currently mounted diskgroup DATA 

AMDU-00201: Disk N0002: ‘/dev/oracleasm/disks/ASMDI SK2' 

AMDU-00204: Disk N0004 is in currently mounted diskgroup DATA 

AMDU-00201: Disk N0004: '/dev/oracleasm/di sks/ ASMDI SK4' 


该 目录 会 默认 生成 下 面 这 组 文件 : 


[grid@localhost ~]$ cd * 22 
[gridglocalhost amdu 2012 04 07 21 54 22]$ Is -| 
total 156160 


-rFw-r--r-- 1 grid oinstall 17200 Apr 7 21:54 DATA.map 
-rFW-r--r-- 1 grid oinstall 159698944 Apr 7 21:54 DATA 0001.i mg 
-rwWer--r-- 1 grid oinstall 9113 Apr 7 21:54 report.txt 


Ж, report.txt 是 磁盘 组 所 包含 的 每 个 磁盘 的 总 体 说 明 ， 其 内 容 如 下 : 


[grid@localhost amdu 2012 04 07 21 54 22]$ cat report.txt 
--*-amdu- *- 


米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 AMDU Settings 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 


ORACLE HOME = /u01/app/grid/product/11.2.0/gri d 


System name: Li nux 

Node name: local host.local domain 

Release: 2.6.18-194.e15 

Version: #1 SMP Mon Mar 29 20:06:41 EDT 2010 

Machi ne: i686 

amdu run: 07- APR- 12 21:54:22 

Endi aness: 1 

ee eee eee б б я я я eee Operations --------------------------------- 
dump DATA 


етте ея т т я т тт т ccc Disk Selection ------------------------------- 
-diskstring '/dev/oracleasm/disks/* 


зт ея т т т е т т я т т я ccc Reading Control ------------------------------- 


eee я ia Output Control ------------------------------- 


米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 DI SCOVERY 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 


9900033999343 DISK REPORT N0001 ---- n eee ee eee 
Disk Path: /dev/oracleasm/disks/ ASMDI SKI 
Uni que Disk ID: 
Disk Label 
Physical Sector Size: 512 bytes 
Disk Size: 7640 megabytes 
Group Name: DATA 
Disk Name: DATA 0000 
Failure Group Name: DATA 0000 
Disk Number: 0 
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Header Status: 

Disk Creation Time: 
Mount Time: 
Compatibility Version 
Disk Sector Size: 

AUs: 
Group Redundancy: 
Metadata Block Size: 

AU Size: 

Stride: 

Group Creation Time: 
File 1 Block 1 location: 
OCR Present 


Last 


Disk size in 


Disk Path: 

Uni que Disk ID: 
Disk Label 

Sector Size: 

Disk Size: 

Group Name: 

Disk Name: 
Failure Group Name 

Disk Number: 

Header Status: 

Disk Creation Ti me: 

Mount Ti me: 
Compatibility Version 

Disk Sector Size: 

AUs: 

Group Redundancy: 

Metadata Block Size: 

AU Size: 

Stride: 

Group Creation Ti me: 

File 1 Block 1 location: 
OCR Present 


Physical 


Last 


Disk size in 


Disk Path: 
Uni que Disk ID: 
Disk Label 
Sector Size: 
Disk Size: 
Group Name: 
Disk Name: 
Failure Group Name 
Disk Number: 
Header Status: 
Disk Creation Ti me: 
Mount Ti me: 
Compatibility Version 
Disk Sector Size: 

Disk size in AUs 


Physical 


Last 


3 

2011/09/18 20:20:28.533000 
2012/03/16 13:06:34.527000 
0x0b200000(11020000 

512 bytes 

7640 AUs 

2 

4096 bytes 

1048576 bytes 

113792 AUs 

2011/09/18 20: 20: 28. 379000 
AU 2 

NO 


DISK REPORT N0002 
/dev/oracleasm/ disks/ASMDI SK2 


512 bytes 

7640 megabytes 

DATA 

DATA_0001 

DATA_0001 

1 

3 

2011/09/18 20: 20: 28. 533000 
2012/03/16 13: 06: 34. 527000 
0x0b200000(11020000 

512 bytes 

7640 AUs 

2 

4096 bytes 

1048576 bytes 

113792 AUs 

2011/09/18 20: 20: 28. 379000 
AU 2 

NO 


DISK REPORT N0003 
Idevloracleasm disks/ASMDISK3 


512 bytes 

5192 megabytes 

AVM_DG 

AVM DG 0000 

AVM DG 0000 

0 

3 

2011/09/18 20:30:22.034000 
2012/03/16 13:06:34.413000 
0x0b200000(11020000 

512 bytes 

5192 AUs 
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Group Redundancy: 
Metadata Block Size: 

AU Size: 

Stride: 

Group Creation Time: 
File 1 Block 1 location: 
OCR Present: 


Disk Path: 
Unique Disk ID: 
Disk Label: 
Sector Size: 
Disk Size: 
roup Name: 
Disk Name: 
Failure Group Name: 
umber: 
Header Status: 
Disk Creation Ti me: 


Physical 


c» 


Disk 


Group Creation Ti me: 
File 1 Block 1 location: 
OCR Present: 


Disk Path: 
Uni que Disk ID: 
Disk Label: 
Sector Size: 
Disk Size: 
roup Name: 
Disk Name: 
ure Group Name: 
umber: 
Header Status: 
Disk Creation Ti me: 
Last Mount Ti me: 
y Version: 
Disk Sector Size: 
Disk size in AUs: 
Group Redundancy: 
Metadata Block Size: 
AU Size: 
Stride: 

Group Creation Ti me: 
File 1 Block 1 location: 


Physical 


Qa 


Fa 


Disk 


Compatibili 


Disk size in AUS: 

Group Redundancy: 
Metadata Block Size: 
AU Size: 


1 
4096 bytes 

1048576 bytes 

113792 AUs 

2011/09/18 20:30:21.882000 
AU 2 

NO 


we DUSK REPORT NOODI M 


| dev/oracleasm/disks/ ASMDI SK4 


512 bytes 

6683 megabytes 

DATA 

DATA 0002 

DATA 0002 

2 

3 

2011/10/28 15:17:35.238000 
2012/03/16 13:06:34.527000 
0x0b200000(11020000) 

512 bytes 

6683 AUs 

2 

4096 bytes 

1048576 bytes 

113792 AUs 

2011/09/18 20:20:28.379000 
AU 2 

NO 


naii ОБЕ NOOS ононе ee ee 


/dev/oracleasm/disks/ASMDISK5 


512 bytes 

6683 megabytes 

DATA 

DATA_0003 

DATA_0003 

3 

3 

2011/10/28 17: 06: 28. 417000 
2012/03/16 13: 06: 34. 527000 
0x0b200000(11020000) 

512 bytes 

6683 AUs 

2 

4096 bytes 

1048576 bytes 

113792 AUs 

2011/09/18 20:20:28.379000 
AU 0 
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OCR Present 


Disk Path: 
Unique Disk ID: 
Disk Label 
Sector Size: 

Disk Size: 
Group Name: 
Disk Name: 

Failure Group Name 
Disk Number: 

Header Status: 

Disk Creation Time: 
Last Mount Time: 
Compatibility Version 
Disk Sector Size: 

Disk size in AUs 
Group Redundancy: 
Metadata Block Size: 
AU Size: 

Stride: 

Group Creation Ti me: 
File 1 Block 1 location: 
OCR Present 


Physical 


KXXEEXEXXX******* Slant for 6 seconds waiting for 


米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 


Creation Time: 

Disks Discovered 
Redundancy: 

AU Size: 

Metadata Block Size: 
Physical Sector Size: 
Metadata Stride: 
Duplicate Disk Numbers 


Disk N0001: '/dev/orac 

AMDU- 00204: Disk N0001 

AMDU- 00201: Disk N0001 
** HEARTBEAT DETECTED ** 

Allocated AU's 

Free AU's: 

read for dump: 

Block images saved 

Map lines written: 

Heartbeats seen: 

Corrupt metadata blocks 

Corrupt AT blocks: 


AU's 


Disk N0002 


NO 


-- DISK REPORT N0006 
| dev/oracleasm/disks/ ASMDI SK6 


512 bytes 

7106 megabytes 

FRA 06 

FRA DG 0000 

FRA DG 0000 

0 

3 

2011/09/18 20:29:41.536000 
2012/03/16 13:06:34.642000 
0x0b200000(11020000 

512 bytes 

7106 AUs 

1 

4096 bytes 

1048576 bytes 

113792 AUs 

2011/09/18 20:29:41.440000 
AU 2 

NO 


SCANNI NG DI SKGROUP DATA ***tx*kskx*kXxkkkdkkkkk*kkk 


2011/09/18 20: 20: 28. 379000 
4 

2 

1048576 bytes 

4096 bytes 

512 bytes 

113792 AU 


- SCANNING DISK N0001 


easm/disks/ ASMDI SK1' 
is in currently mounted diskgroup DATA 
'[dev/oracleasm/di sks/ ASMDI SK1' 


1414 
6226 
56 
10006 
56 


- SCANNING DISK N0002 


'[dev/oracleasm/di sks/ ASMDI SK2' 


heartbeats LEE E E E E E E E E E E E E E E 
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AMDU- 00204: Disk N0002 is in currently mounted diskgroup DATA 
AMDU-00201: Disk N0002: '/dev/oracleasm/di sks/ ASMDI SK2' 
** HEARTBEAT DETECTED ** 
Allocated AU's: 1413 
Free AU's: 6227 
AU's read for dump: 56 
Block images saved: 10262 
Map lines written: 56 
Heartbeats seen: 1 
Corrupt metadata blocks: 0 
Corrupt AT blocks: 0 


Fee яя ee ee eee eee ee eee SCANNING DISK N0004 ------- M 
Disk N0004: '/dev/oracleasm/disks/ ASMDI SK4' 
AMDU-00204: Disk N0004 is in currently mounted diskgroup DATA 
AMDU-00201: Disk N0004: '/dev/oracleasm/di sks/ ASMDI SK4' 
** HEARTBEAT DETECTED ** 
Allocated AU's: 1276 
Free AU's: 5407 
AU's read for dump: 55 
Block images saved: 10257 
Map lines written: 55 
Heartbeats seen: 1 
Corrupt metadata blocks: 0 
Corrupt AT blocks: 0 


i SCANNING DISK N0005 ----------------------------- 
Disk N0005: '/dev/oracleasm/disks/ ASMDI SK5' 
Allocated AU's: 1266 
Free AU's: 5417 
AU's read for dump: 48 
Block images saved: 8464 
Map lines written: 48 
Heartbeats seen: 0 
Corrupt metadata blocks: 0 
Corrupt AT blocks: 0 


MM] c] я я яя я я я яя eee SUMMARY FOR DISKGROUP DATA ------------------------- 
Allocated AU's: 5369 
Free AU's: 23271 
AU's read for dump: 215 
Block images saved: 38989 
Map lines written: 215 
Heartbeats seen: 3 
Corrupt metadata blocks: 0 
Corrupt AT blocks: 0 


ЕЕЕ ЕЕЕ ЕКЕЖ ЕКЕЖ ЕМ) OF REPORT КАЖЕ ЕЕРЕЕ 
DATA.map 记录 了 人 磁盘 组 中 元 数据 文件 的 扩展 分 配 表 及 其 在 img 文件 中 的 位 置 ,其 内 容 如 下 : 


[gridglocalhost amdu 2012 04 07 21 54 22]$ cat DATA. map 
N0001 D0000 ROO А00000000 F00000000 10 E00000000 000 C00256 50001 B0000000000 
N0001 D0000 ROO А00000001 F00000000 10 E00000000 000 C00256 50001 B0001048576 
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0001 D0000 ROO A00000002 F00000001 
0001 D0000 ROO A00000003 F00000002 
0001 D0000 ROO A00000005 F00000003 
0001 D0000 ROO A00000006 F00000003 


E00000000 U00 C00256 S0001 B0002097152 
E00000001 U00 C00256 S0001 B0003145728 
E00000003 U00 C00256 S0001 B0004194304 
E00000007 U00 C00256 S0001 B0005242880 


о о о c 


0005 D0003 ROO A00000916 F00000266 
0005 D0003 ROO A00000941 F00000267 


E00000002 U00 C00001 S0001 B0159678464 
E00000002 U00 C00001 50001 B0159682560 
0005 D0003 ROO A00001118 F00000269 E00000000 U00 C00002 S0001 80159686656 
0005 D0003 ROO A00001143 F00000271 E00000002 U00 C00001 S0001 B0159694848 


DATA. 0001.img 是 磁盘 组 中 元 数据 的 DUMP 映像 ， 每 个 文件 最 大 为 1 СВ. 
2. 通过 文件 号 导出 ASM 文件 
以 下 命令 将 导出 磁盘 组 DATA 中 文件 号 为 257 的 文件 : 


amdu -diskstring '/dev/oracleasm/disks/*' -dump 'DATA' -norep -nodir -extr DATA.257 
-output sysaux. dbf 


以 下 命令 用 于 确认 257 号 文件 是 否 被 导出 : 


[grid@l ocal host ~]$ Is -| ѕуѕаих. dbf 
-rwWer--r-- 1 grid oinstall 817897472 Арг 7 22:10 sysaux. dbf 


以 下 命令 用 于 验证 导出 的 数据 文件 是 否 正确 : 


[gridglocalhost ~] $ dbfsize sysaux. dbf 
Database file: sysaux. dbf 

Database file type: file system 

Database file size: 99840 8192 byte blocks 


3. 通过 文件 名 导出 ASM 文件 
以 下 命令 将 生成 磁盘 组 DATA 的 所 有 别名 信息 ，D1.A49 从 DATA.map 中 获取 ， 其 对 应 的 文 
件 号 为 F00000006: 


[grid@l ocal host ~]$ amdu -diskstring '/dev/oracleasm/disks/*' -dump 'DATA' -norep 

-nodir -print DATA. D1. A49. B0. C256 > dir.txt 

AMDU- 00204: Disk №001 is in currently mounted diskgroup DATA 

AMDU- 00201: Disk N0001: '/dev/oracleasm/disks/ ASMDI SK1' 

AMDU-00204: Disk N0002 is in currently mounted diskgroup DATA 

AMDU-00201: Disk N0002: '/dev/oracleasm/disks/ ASMDI SK2' 
U 
U 


Prep 


AMDU- 00204: Disk N0004 is in currently mounted diskgroup DATA 
AMDU- 00201: Disk N0004: '/dev/oracleasm/di sks/ ASMDI SK4' 


从 上 面 命令 生成 的 dirtxt 中 搜寻 想 要 导出 的 别名 及 文件 号 , 比如 SYSTEM, 其 文件 号 为 256: 


id@l ocal host ~]$ vi dir.txt 


[9 

k d 0]. entry. і псагп: 1; 0x024: А=1 NUMM=0x0 
kfade[ 0]. entry. hash: 2097622492 ; 0x028: 0x7d072ddc 
kfade[O].entry.refer.number: 4294967295 ; 0x02c: Oxffffffff 
kfade[0].entry.refer.incarn: 0 ; 0x030: A=0 NUMM=0x0 
kfade[0]. name: SYSTEM ; 0x034: lengthz6 
kfade[0].fnum 256 ; 0x064: 0x00000100 
kfade[0].finc: 762214281 ; 0x068: 0x2d6e7789 
kfade[0].flags: 18 ; 0x06c: U=0 S=1 S=0 U=0 F=1 
kfade[0].ublspare: 0 ; 0x06d: 0x00 
kfade[0].ub2spare: 0 ; 0x06e: 0x0000 
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最 后 通过 以 下 命令 导出 磁盘 组 DATA 中 的 文件 号 为 256 的 SYSTEM 数据 文件 : 


amdu -diskstring '/dev/oracleasm/disks/*' -dump ' DATA' -norep -nodir -extr DATA.256 
-output system. dbf 


4. 磁盘 头 损坏 的 导出 
以 下 命令 可 以 在 磁盘 头 损坏 的 情况 下 生成 磁盘 组 DATA 的 元 数据 块 布局 报告 : 


[gridglocalhost -]$ amdu -diskstring '/dev/oracleasm/disks/*' -ba 'DATA' -ausize 
1048576 -blksize 4096 

amdu 2012 04 07 22 16 33/ 

AMDU- 00204: Disk N0001 is in currently mounted diskgroup DATA 

AMDU-00201: Disk N0001: '/dev/oracleasm/di sks/ ASMDI SKI1' 

AMDU-00204: Disk N0002 is in currently mounted diskgroup DATA 

AMDU-00201: Disk N0002: '/dev/oracleasm/di sks/ ASMDI SK2' 

AMDU-00204: Disk N0004 is in currently mounted diskgroup DATA 

AMDU-00201: Disk N0004: '/dev/oracleasm/disks/ ASMDI SK4' 


5. 分 配 表 损 坏 的 导出 
以 下 命令 可 以 在 磁盘 分 配 表 损 坏 的 情况 下 生成 磁盘 组 DATA 的 元 数据 块 布局 报告 : 


[gridglocalhost ~] $ amdu -diskstring '/dev/oracleasm/disks/*' -ba 'DATA' -ausize 
1048576 -blksize 4096 -fullscan 

amdu 2012 04 07 22 18 38/ 

AMDU- 00204: Disk №001 is in currently mounted diskgroup DATA 

AMDU-00201: Disk N0001: '/dev/oracleasm/di sks/ ASMDI SKI1' 

AMDU-00204: Disk N0002 is in currently mounted diskgroup DATA 

AMDU-00201: Disk N0002: '/dev/oracleasm/di sks/ ASMDI SK2' 

AMDU-00204: Disk N0004 is in currently mounted diskgroup DATA 

AMDU-00201: Disk N0004: '/dev/oracleasm/di sks/ ASMDI SK4' 


理解 数据 块 结构 


老 白 曾 在 《Oracle 优化 日 记 》 一 书 中 ， 通 过 一 个 使 用 bbed 修复 系统 的 示例 对 数据 块 结构 做 
过 一 些 介 绍 。 不 过 这 些 年 DBA 群体 对 于 数据 块 结构 的 研究 越 来 越 多 ， 这 是 因为 从 Oracle 10g 版 
本 开始 ，Oracle 对 аш 工具 设置 了 使 用 时 间 的 限制 ， 除 非 购买 Oracle 原矿 的 现场 服务 ， 和 否则 很 难 
找到 这 个 工具 。 另 外 ， 随 着 数据 瓜 救 的 需求 越 来 越 多 ，dul 注重 数据 一 致 性 的 风格 ， 使 得 它 在 处 
理 某 些 极端 需求 时 显得 无 能 为 力 。 

实际 上 ， 编 写 一 些 数据 抒 救 工具 ， 对 于 每 个 具有 一 定编 程 能 力 的 DBA 来 说 都 不 是 很 难 ， 目 
前 他 们 最 为 缺乏 的 只 是 对 数据 块 结构 的 一 些 基本 了 解 。 本 章 同样 是 由 老 储 编写 的 , 希望 下 面 的 内 
容 对 于 想 编写 类 似 dul 这 种 数据 拯救 工具 的 朋友 有 所 帮助 。 
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数据 块 是 数据 库 进 行 磁盘 VO 和 信息 存储 的 最 小 单位 , 可 以 有 多 种 大 小 : 2KB 、4KB 、8KB、 
16 KB 或 32 КВ. 数据 库 创建 时 需要 指定 默认 的 块 大 小 , 主要 用 于 系统 、UNDO 和 TEMP 表 空 间 ， 
而 每 个 用 户 创建 的 表 空 间 可 以 使 用 不 同 的 块 大 小 。 不 管 块 大 小 取 多 少 , 每 个 数据 块 的 块头 结构 都 
ШЕН), Jf ASA) WORD (16 位 ) 和 INTEGER (32 位 ) 的 字 节 顺序 (Endian ) 和 所 处 平台 
的 字 节 顺序 一 致 ， 这 样 做 的 好 处 是 可 以 获得 最 佳 的 性 能 , 但 是 不 能 保证 数据 库 的 跨 平台 移植 。 当 
然 ,， 如 果 两 个 异种 平台 的 字 节 顺序 是 一 致 的 ， 使 用 Oracle 10g 以 上 的 版 本 也 是 可 以 移植 的 ， 通过 
查询 VSTRANSPORTABLE_PLATFORM 视图 可 以 了 解 不 同 平台 之 间 的 移植 性 。 数 据 块头 结构 随 
版 本 的 不 同 可 能 会 有 差异 , 我 们 主要 接触 到 的 有 V7 和 V8, 8.0 以 后 的 版 本 基本 上 保持 着 兼容 性 。 
数据 块 有 多 种 类 型 ， 每 种 类 型 的 结构 也 各 不 相同 ， 但 是 所 有 的 数据 块 都 包含 相同 的 头 结构 一 一 
kcbh。 以 V8 的 数据 块 为 例 ， 块 头 由 20B 组 成 ， 位 于 块 的 起 始 部 分 ， 主 要 结构 如 下 : 


Ёш 


e e e e de жс eI] e e eI + 
| 0 | 1 |2 p 4&7 | 8-211 | 3233] 14 | 15 | 16-17 | 18-19 | 
+- e 4e 4e 4e 4e eI e 4e 4e + 
| 类 型 | 格式 | 填充 | RDBA |SCN BASE|SCN WRAP| 序列 号 | 标志 | 校 验 和 | 填充 | 
e el e e Е e eI] Ree el M el + 


下 面 按照 顺序 介绍 每 个 字段 的 含义 。 
O 类 型 ( type_kcbh ) 定义 了 该 块 的 用 途 ， 主 要 有 以 下 几 种 : 
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0 = none. 

1 = KTU UNDO HEADER 

2 = KTU UNDO BLOCK 

3 = SAVE UNDO HDR 

4 = SAVE UNDO BLOCK 

5 = DATA SEG HDR 

6 = KTB MANAGED (with ITL) 

7 = TEMP DATA (no itl) 

8 = SORT KEY 

9 - SORT RU 

10 = SEG FREE LIST 

11 = DATA FILE HDR 

12 = DATA SEG HDR with Free List Groups 
13 = Compatibility SEG 

14 = unlimited undo segment header 

15 = unlimited save undo segment header 
16 = unlimited data segment header 

17 = unlimited data segment header with flg blks 
18 = extent map block 

19 - backup set piece header 

20 = backup set directory block 

21 = control file block 

22 = segment free list block with #blks in freelists 
23 - bitmapped segment header 

24 - bitmapped freelist block 

25 = bitmap index block 

26 - bitmap block 

27 = LOB block 

28 - funny undo block (for future use) 
29 - bitmapped file space header 

30 - bitmapped file space bitmap block 
31 = temporary seg based index 

32 = First level bitmap block 

33 = second level bitmap block 

34 = third level bitmap block 

35 - Pagetable segment header block 

36 - Pagetable extent map block 

37 = System Managed Undo Extent Map Block 
38 = System Managed Segment Header Block 
39 = SPFILE backup block 

40 - pagetable managed LOB block 

4l = max value for block header validation 


О 格式 (type kcbh ) 主要 包括 : 


Oracle? 
Oracle8 以 上 


口 RDBA (rdba_kcbh ): 该 块 的 相对 数据 库 地 址 ， 共 32 位， 高 10 位 表示 相对 文件 号 ， 低 22 

位 表示 块 号 。 

О SCN BASE ( bas kcbh ), SCN WRAP ( wrp_kcbh ): 对 应 着 当前 REDO 生成 的 SCN, SCN 
H SCN BASE #1 SCN WRAP 两 部 分 组 成 。 
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O 序列 号 (seq_kcbh ): 在 相同 的 SCN F, 该 块 可 能 会 产生 多 次 变化 , 使 用 序列 号 进行 区 分 ， 
如 果 SCN 增长 ， 序 列 号 复位 为 1。 

О 标志 (flg_kcbh ) 由 一 些 位 值 组 合 而 成 COR 操作 )， 这 些 位 值 主要 包括 : 

KCBHFNEW 0x01 — /] dX 

KCBHFDLC 0x02 // 数据 块 延迟 清洗 推进 SCN 和 序列 号 


KCBHFCKV 0x04 11 设置 校 验 和 
KCBHFTMP 0x08 [1 临时 块 


O 校 验 和 (chkval_kcbh ): 可 选 ， 如 果 设 置 了 初始 化 参数 DB BLOCK CHECKSUM, 将 会 

启用 校 验 和 检查 数据 块 的 一 致 性 。 

另外 ,数据 块 的 最 后 4 字 节 为 块 尾 (tail )， 可 以 配合 数据 块头 来 验证 数据 块 的 一 致 性 。 它 的 
结构 为 : 


SCN BASE 的 2 位 低 字 节 + 块 类 型 + 序列 号 
如 果 一 个 块 被 标识 成 软 损 坏 ， 那 么 其 块头 的 序列 号 为 Off, PREA 0x00。 
下 面 分 别 介绍 字 节 顺序 不 同 的 平台 上 的 数据 块头 。 
О Linux 平台 : 小 端 ， 低 位 字 节 在 低地 址 。 
Block: 242 Offsets: 0 to 19 


06020000 f2004000 688c0200 00000106 


46bf 0000 

struct kcbh, 20 bytes Q0 
ubl type kcbh Q0 0x06 -- RI 索引 块 
ubl frmt kcbh Q1 0x02 -- V8 
ubl sparel kcbh Q2 0x00 
ubl spare2 kcbh Q3 0x00 
ub4 rdba kcbh Q4 0x004000f12 -- 35, FMR AS 
ub4 bas kcbh Q8 0x00028c68 
ub2 wrp kcbh @12 0x0000 
ubl seq_kcbh @14 0x01 
ubl flg_kcbh @15 0x06 (KCBHFDLC, KCBHFCKV) 
ub2 chkval kcbh @16 Oxbf 46 -- KCBHFCKV 表示 需要 校 验 和 
ub2 spare3 kcbh 918 0x0000 

О AIX 平 台 : 大 端 ， 高 位 字 节 在 低地 址 。 
Block: 122 Offsets: 0 to 19 


06020000 0040007a 934e5bcl 00950106 


bd5a0000 
struct kcbh, 20 bytes Q0 
ubl type kcbh Q0 0x06 
ubl frmt kcbh Q1 0x02 
ubl sparel kcbh Q2 0x00 
ubl spare2 kcbh Q3 0x00 
ub4 rdba kcbh @4 0x0040007a -- Хз, FUMPRE RH 
ub4 bas kcbh Q8 0x934e5bcl 


ub2 wrp kcbh 912 0x0b95 
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ubl seq_kcbh @14 0x01 
ubl flg kcbh @15 0x06 (KCBHFDLC, KCBHFCKV) 
ub2 chkval_kcbh @16 Oxbd5a 
ub2 spare3_kcbh @18 0x0000 
9.2 理解 ITL 


事务 型 的 数据 块 〈 类 型 为 6 ) 存放 表 和 索引 数据 ， 其 结构 主要 由 块头 、 事 务 层 、 数 据 层 和 块 
尾 4 部 分 组 成 。 

其 中 , 事务 层 由 头 结 构 和 ITL (Interested Transaction Slots ) 构成 。ITL 是 一 个 可 变 长 的 数组 ， 
当 某 个 事务 修改 或 准备 修改 (forupdate ) 该 块 中 的 行 数据 时 ,首先 会 在 ITL 中 寻找 一 个 空闲 的 插 
槽 ， 如 果 没 找到 ， 就 动态 扩展 ITL， 然 后 在 空闲 插 模 中 填写 相关 的 事务 信息 。 事 务 层 头 结构 从 块 
偏 移 20 开始 ， 其 结构 ktbbh Jy: 


+ e e ecce e ec e Ree + 
| 0 | 1-3 | 4-7 | 8-15 | 16-17 | 18 | 19 | 20-23 
e e + + + e e FR + 
| 块 类 型 | 填充 | 对 象 段 号 | 最 后 清洗 5CN | ITL] 标志 | # | 块 指针 | 
e e e ecce e e e Fee + 
下 面 分 别 介绍 每 个 字段 的 含义 。 
о 块 类 型 (ktbbhtyp ) 可 取 以 下 值 : 
1 = DATA 
2 = INDEX 
а 对 象 段 号 (ktbbhsid ) 是 数据 库 对 象 所 使 用 的 段 的 编号 ， 表 示 该 块 中 的 所 有 行 数据 属于 
该 段 。 


а 最 后 清洗 SCN (ktbbhesc ) 是 该 块 最 后 一 次 执行 清洗 时 的 SCN。 
а ITL 数 (ktbbhict ) 记录 了 ITL 数 组 的 长 度 。 
о 标志 (ktbbhflg ) 由 一 些 位 值 组 合 而 成 ( OR 操作 )， 这 些 位 值 主要 包括 : 


KTBFONFL 0x01 // 块 在 Free List 中 
KTBFBSEG 0x10 // 块 使 用 位 图 管理 空 闪 空间 
KTBFEXTHD 0x20 J| 支持 扩展 的 事务 头 


о 锁 (ktbbhfsl ) 是 一 个 复 用 的 字段 ， 如 果 数 据 块 采用 位 图 管理 空闲 空间 CASSM Ez), 那么 
该 字段 表示 该 块 所 处 位 图 数组 的 搬 槽 号 ， 如 果 数 据 块 使 用 Free List 管理 空闲 空间 (FLM 
ER), 那么 该 字段 用 于 事务 型 Free List 的 操作 。 

а 块 指针 (ktbbhfnx ) 是 另 一 个 复 用 的 字段 , 如 果 数 据 块 采 用 位 图 管理 空闲 空间 ( ASS Б), 
那么 该 字段 表示 11 块 的 块 地 址 ; 如 果 数 据 块 使 用 Free List 管理 空闲 空间 (ЕМ), ЭЁ 
么 该 字段 指向 Free List 中 的 下 一 个 块 。 

ITL 数组 的 每 个 插 模 由 24 个 字 节 组 成 ， 从 块 偏 移 44 或 52 (如 果 使 用 位 图 管理 ) 开始 ， 其 结 

№ ktbit 为 : 


228 第 9 章 理解 数据 块 结构 


e e ЕЕ +- M +- 4 eee +- ТЕЕ + 
0-1 | 23 | 47 | 8-14 | 15 [16-17] 18-19 | 20-23 | 
el el] +- M +- e efe +- eens +- M + 
回 滚 段 | AAS | UNDO WRAP| UNDO 地 址 | 保留 | 标志 | SCN WRAP|SCN BASE | 
e eI ТЕЕ +- eens +- eee +- ТЕЕ + 


每 个 字段 的 含义 如 下 所 示 。 

O 回 滚 段 (kxidusn ) 是 对 应 事务 所 在 的 回 滚 段 编号 。 

О 插 模 号 (kxidslt ) 是 对 应 事务 在 回 深 段 事务 表 中 的 插 权 号 。 

О UNDO WRAP ( kxidsqn ) 是 对 应 事务 在 回 滚 段 事务 表 中 的 WRAP 值 ， 它 和 前 两 个 字段 一 

起 唯一 标识 了 一 个 事务 ， 相 当 于 事务 的 主键 。 

О UNDO 地 址 (ktbituba ) 是 最 后 生成 的 UNDO 记录 的 地 址 ， 格 式 为 : 

UNDO DBA (4 #717 ) + 序列 号 (2 字 节 ) + 记录 号 (1 字 节 ) 

о 如 果 某 个 行 在 事务 中 被 连续 改变 了 多 次 ， 每 次 都 会 生成 UNDO 记录 ， 这 些 记录 就 被 反问 
链接 在 一 起 ， 后 一 个 指向 前 一 个 ， 这 样 在 执行 回 滚 时 ， 可 以 从 后 往 前 逐个 实施 UNDO ir 
录 ， 最 终 回 滚 到 某 个 保存 点 或 事务 的 起 点 。 

O 标志 Cktbitflg ) 由 两 部 分 组 成 ， 高 4 位 表示 事务 的 提交 状态 ， 低 12 位 保存 该 事务 修改 的 

本 块 的 行 数 ， 事 务 的 提交 状态 由 一 些 位 值 组 合 而 成 COR 操作 )， 这 些 位 值 主 要 包括 : 


KTBFCOM 0x8000 // 事务 已 提交 

KTBFI B| 0x4000 // 使 用 ktbituba 指向 的 UND0 记录 回 滚 可 以 获得 本 |1TL Aas aT ERR 
KTBFUPB 0x2000 // 事务 提交 5CN 是 个 上 边界 ， 不 一 定 精确 

KTBFTAC 0x1000 // 事务 在 最 后 清洗 时 (ktbbhcsc) 尚未 提交 


O SCN WRAP (_ktbitun ): 该 字段 复 用 ,如 果 事 务 已 提交 并 完成 清洗 ， 该 字段 保存 事务 提交 
SCN 的 SCN WRAP 部分， 否则 该 字段 保存 空闲 空间 预支 字 节 数 ( Free Space Credit )。 比 
如 ， 删 除 一行 可 以 释放 80B 字 节 ,在 事务 提交 前 ， 这 80B 就 属于 fsc， 只 有 事务 提交 后 ， 
才能 正式 返回 到 空闲 空间 。 

口 SCN BASE ( ktbitbas ); 事务 提交 SCN 的 SCN BASE 部 分 。 

我 们 看 一 个 例子 : 初始 插 槽 为 2。 

Linux 平台 : 小 端 ， 字 节 顺 序 需要 反 转 

Block: 83362 Offsets: 20 to 91 


01000000 59760000 df5be300 00000000 
02000300 00000000 02000800 a5980000 
43008000 84092500 07200000 a85ce300 
00000000 00000000 00000000 00000000 
00000000 00000000 


struct ktbbh, 72 bytes @20 事务 层 头 结构 
ubl ktbbhtyp @20 0x01 (KDDBTDATA) 
union ktbbhsid, 4 bytes Q24 
ub4 ktbbhsgl @24 0x00007659 
ub4 ktbbhodl @24 0x00007659 
struct ktbbhcsc, 8 bytes @28 
ub4 kscnbas @28 0x00e35bdf 


ub2 kscnwrp 932 0x0000 
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b2 ktbbhict @36 0x0002 - 两 个 1 TL 4645 
ubl ktbbhflg 38 0x03 (KTBFONFL) --Free List 管理 
ubl ktbbhfsl Q39 0x00 
ub4 ktbbhfnx 940 0x00000000 
struct ktbbhitl[0], 24 bytes 944 第 一 个 1TL 4545 
struct ktbitxid, 8 bytes (944 - 事务 标识 
ub2 kxidusn @44 0x0002 
ub2 kxidsit @46 0x0008 
ub4 kxidsqn @48 0х000098а5 
struct ktbituba, 8 bytes @52 - 最 后 UND0 记录 地 址 
ub4 kubadba @52 0x00800043 
ub2 kubaseq (95 6 0x0984 
ubl kubarec (95 8 0x25 
ub2 ktbitflg @60 0х2007( КТВРОРВ) - - 该 事务 修改 了 7 fF 
union _ktbitun, 2 bytes @62 
b2 _ktbitfsc @62 0 
ub2 _ktbitwrp @62 0x0000 
ub4 ktbitbas Q6 4 0x006e35ca8 
struct ktbbhitl[1], 24 bytes 68 第 二 个 1TL 46435 
struct ktbitxid, 8 bytes @68 
ub2 kxidusn @68 0x0000 
ub2 kxidslt @70 0x0000 
ub4 kxidsqn @72 0x00000000 
struct ktbituba, 8 bytes @76 
ub4 kubadba @76 0x00000000 
ub2 kubaseq Q8 0 0x0000 
ubl kubarec Q8 2 0x00 
ub2 ktbitflg Q8 4 0x0000 (NONE) - ` 4548 AAR A 
union _ktbitun, 2 bytes (98 6 
b2 ktbitfsc (Q8 6 0 
ub2 ktbitwrp Q8 6 0x0000 
ub4 ktbitbas 88 0x00000000 


为 什么 
在 创建 表 或 索引 时 , 可 以 指定 


的 低 端 往 高 端 进行 的 ， 正 好 和 行 数据 相反 。 
24B， 如 果 数 据 块 无 足够 的 空闲 空间 ， 


插 槽 数 。 如 果 茶 个 事务 在 ITL 中 没有 找到 空 


要 设置 IN|_TRANS 参数 


INI TRANS 参数 , 该 参数 定义 了 表 或 索引 数据 块 中 预 留 的 ITL 


s 闲 的 插 槽 ， 


就 会 
行 数据 是 从 高 端 往 低 端 分 配 的 ， 每 个 ITL 插 模 需要 
就 会 产生 等 待 事件 enq: TX - allocate ITL entry. 


动态 扩展 ITL， 这 种 扩展 是 从 数据 块 


当 占 用 ITL 插 模 的 某 个 事务 提交 或 回 深 后 , 释放 了 ITL HB, 正在 等 待 的 事务 才能 继续 进行 


下 去 。 这 种 现象 一 般 出 现在 表 上 有 很 多 并 发 事务 执行 UPDATE 操作 的 情况 下 ,解决 的 办 法 


加 表 及 索引 的 INI. TRANS 值 。 


法 是 增 


默认 情况 下 ， 表 的 INL TRANS 值 是 2， 索 引 的 INI TRANS 值 也 


护 内 部 事务 。 增 加 INI TRANS 值 有 两 种 方法 。 


INITRANS 值 被 指定 


52, 索引 自身 的 维护 (节点 分 裂 ) 是 一 个 内 部 事务 ， 需 要 ITL HRS, fA 


0 被 保留 用 于 索引 维 


a 创建 表 或 索引 时 ， 指 定 INITRANS 值 ， 将 对 所 有 的 数据 块 起 作用 。 
а 表 或 索引 被 创建 后 ， 修 改 INITRANS 值 ， 只 对 修改 后 新 建 的 数据 块 起 作用 。 
为 3 时 ，ITL 搬 权 的 初始 分 配 情况 如 代码 清单 9-1 所 示 : 
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代码 清单 9-1 
Linux 平台 : 小 端 ， 字 节 顺 序 需要 反 转 


Block: 83362 Offsets: 20 to 115 
01000000 59760000 998de300 00000000 
03000300 00000000 02000a00 c1980000 
3f008000 85092a00 01000000 00000000 
03000000 c9990000 60008000 d2090900 
01000000 00000000 09000500 c3990000 
26018000 83091d00 01000000 00000000 
struct ktbbh, 96 bytes @2 0 
ubl ktbbhtyp @20 0x01 (KDDBTDATA) 
union ktbbhsid, 4 bytes Q24 
ub4 ktbbhsgl @24 0x00007659 
ub4 ktbbhodl @24 0x00007659 
struct ktbbhcsc, 8 bytes @28 
ub4 kscnbas @28 0x00e38d99 
ub2 kscnwrp 932 0x0000 
b2 ktbbhict 36 3 - -1TL 播 槽 号 为 3 
ubl ktbbhflg @38 0x03 (KTBFONFL) 
ubl ktbbhfsl @39 0x00 
ub4 ktbbhfnx @40 0x00000000 
struct ktbbhitl[0], 24 bytes (944 第 一 个 1TL 46545 
struct ktbitxid, 8 bytes 944 
ub2 kxi dusn 944 0x0002 
ub2 kxidslt Q4 6 0x000a 
ub4 kxidsqn (948 0x000098c1 
struct ktbituba, 8 bytes (952 
ub4 kubadba @52 0x0080003f 
ub2 kubaseq (95 6 0x0985 
ubl kubarec (95 8 0x2a 
ub2 ktbitflg (60 0x0001 (NONE) 
union ktbitun, 2 bytes (96 2 
b2 ktbitfsc Q6 2 0 
ub2 ktbitwrp @6 2 0x0000 
ub4 ktbitbas @64 0x00000000 
struct ktbbhitl[1], 24 bytes (68 第 二 个 1TL 4645 
Struct ktbitxid, 8 bytes @68 
ub2 kxidusn @68 0x0003 
ub2 kxidslt @70 0x0000 
ub4 kxidsqn @72 0x000099c9 
struct ktbituba, 8 bytes Q76 
ub4 kubadba Q7 6 0x0080006b 
ub2 kubaseq Q8 0 0x09d2 
ubl kubarec (982 0x09 
ub2 ktbitflg Q8 4 0x0001 (NONE) 
union ktbitun, 2 bytes (98 6 
b2 ktbitfsc (98 6 0 
ub2 ktbitwrp (98 6 0x0000 
ub4 ktbitbas (98 8 0x00000000 
struct ktbbhitl[2], 24 bytes @92 第 三 个 1TL 46546 
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struct ktbitxid, 8 bytes Q9 2 

ub2 kxidusn Q9 2 0x0009 

ub2 kxidslt Q9 4 0x0005 

ub4 kxi dsqn Q9 6 0x000099c3 
struct ktbituba, 8 bytes 9100 

ub4 kubadba 9100 0x00800126 

ub2 kubaseq 9104 0x0983 

ubl kubarec 9106 0х1 
ub2 ktbitflg 9108 0x0001 (NONE) 
union _ktbitun, 2 bytes 9110 

b2 ktbitfsc 9110 0 

ub2 _ktbitwrp @110 0x0000 
ub4 ktbitbas @112 0x00000000 


9.3 理解 记录 结构 


表 中 的 数据 以 记录 或 行 的 形式 保存 在 事务 型 的 数据 块 ( kcbh.type_kcbh=6 3f H. 
ktbbh.ktbbhtyp=1 ) F, 它们 位 于 数据 块 的 数据 层 。 表 记录 的 数据 层 包括 头 结构 、 表 索引 、 行 索引 
和 行 数据 。 

头 结构 在 块 中 的 起 始 位 置 可 以 按 以 下 公式 计算 。 

О 对 于 Free List 管理 空闲 空间 (FLM ) 的 数据 块 : 44+ITLs*24。 
а 对 于 位 图 管理 空闲 空间 ( ASSM ) 的 数据 块 : S2+ITLs*24。 
头 结构 kdbh 由 以 下 字段 组 成 : 


el el el 4e e 4e 4e de 4 + 
0 | 1 | 2-3] 45 | 6&7 | 8-9 | 10110 | 12-13 | 
el el el 4e eM e 4e E + 
标志 | АЖ | 行 数 | SASH 起 始 空间 | 结束 空间 | 空闲 空间 | ”最终 空闲 空间 
el el Ree 4e . MM + + + + 


每 项 的 含义 如 下 所 示 。 

а 表 数 ( kdbhntab ) 定义 了 表 索 引 数组 的 长 度 。 

О 行 数 ( kdbhnrow ) 定义 了 行 索 引 数组 的 长 度 。 

О 空闲 行 搬 槽 ( kdbhfrre ) 定义 了 行 索引 数组 中 第 一 个 空闲 的 搬 模 号， 如 果 没 有 空闲 的 ， 则 

为 OxFFFF 

о 起 始 空间 ( kdbhfsbo ) 定义 了 数据 层 中 空闲 空间 的 起 始 偏 移 。 

a 结束 空间 ( kdbhfseo ) 定义 了 数据 层 中 空闲 空间 的 结束 偏 移 。 

О 空 闪 空间 ( kdbhavsp ) 定义 了 数据 层 中 空闲 空间 的 字 节 数 。 

а 最 终 空 闲 空间 ( kdbhtosp ) 定义 了 ITL 中 的 事务 提交 后 ， 数 据 层 中 空闲 空间 的 字 节 数 。 
表 索 引 是 一 个 数组 , 定义 了 行 数据 可 能 包括 的 表 ， 由 于 艇 可 能 包含 多 个 表 , 这 些 表 在 物理 存 

储 上 使 用 同一 个 段 ， 它 们 相关 的 行 (拥有 相同 的 簇 值 ) 被 放 在 一 起 ，Oracle 在 设计 数据 层 的 结构 

时 考虑 到 了 这 一 点 ， 通 过 表 索 引 来 区 分 相关 的 行 属于 哪 一 个 表 。 表 索引 的 插 槽 由 4 个 字 节 组 成 ， 

其 结构 kdbt 如 下 : 
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ee ee + 
偏 移 | 行 数 | 
ee ee + 
每 项 的 含义 如 下 所 示 。 
о 偏 移 (kdbtoffs ) 定义 了 该 表 在 行 索引 中 的 起 始 插 模 号 。 
O 行 数 (kdbtnrow ) 定义 了 该 表 在 行 索引 中 使 用 的 插 槽 数 。 
对 于 非 徐 表 ， 表 索引 只 有 一 个 插 槽 ， 而 对 于 簇 表 ， 表 索引 可 能 有 多 个 插 柳 ， 每 个 插 横 对 应 簇 
中 的 一 个 表 ， 对 应 关系 为 : 插 权 号 =obj$ 表 中 的 tab# 列 。 正 因为 如 此 ， 即 使 徐 中 的 某 个 表 没 有 对 应 
Mids, RAP, CRANE AMA, ITA 0. 
行 索引 也 是 一 个 数组 ,定义 了 该 块 中 包含 的 所 有 行 数据 的 位 置 。 行 索引 的 插 覃 由 2 个 字 节 组 
成 ， 其 结构 kdbr 如 下 : 


| 偏 移 | 
el + 


偏 移 定 义 了 该 行 数据 在 数据 层 中 的 偏 移 字 节 。 在 计算 该 行 数据 在 块 中 的 偏 移 值 时 , 还 要 加 上 
数据 层 自身 的 侦 移 值 。 
行 数 据 由 行头 和 各 列 值 组 成 ， 行 头 的 基本 结构 kdrh OY : 


el ee eI + 
| 0 | 1 | 2 | 
e eI e M + 
| 标志 | 行 锁 | 列 数 | 
e eI 4e + 


每 项 的 含义 如 下 所 示 。 
о 标志 (kdrhflag ) 由 一 些 位 值 组 合 而 成 (OR 操作 )， 这 些 位 值 主 要 包括 : 


KDRHFK 0x80 || Ж®Ж 

KDRHFC 0x40 I] SAGA 

KDRHFH 0x20 11 行头 

KDRHFD 0x10 || 已 删除 

KDRHFF 0x08 11 第 一 个 分 片 

KDRHFL 0x04 1 1 最 后 一 个 分 片 

KDRHFP 0x02 || DRA РЖ я] а ЕА 
KDRHFN 0x01 || 分 片 中 的 最 后 一 列 将 在 下 一 分 片 继续 


О 行 锁 (kdrhlock ) 是 用 修改 该 行 的 事务 在 ITL 中 的 插 槽 号 来 表示 的 。 
О 列 数 ( kdrhccnt ) 定义 了 本 行 数据 包含 的 列 数 。 

在 一 般 情况 下， 紧邻 行头 的 就 是 各 个 列 的 数据 ， 其 结构 为 该 列 数 据 的 长 度 和 实际 数据 。 列 的 
长 度 为 1 ~3 B， 如 果 第 一 个 字 节 为 Off, RRINE (NULL); 如 果 第 一 个 字 节 为 Oxfe, JE 
么 后 两 位 表示 字 节 的 长 度 , 否则 第 一 个 字 节 表示 列 数据 的 长 度 。 列 在 数据 行 中 的 顺序 一 般 和 表征 
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义 中 的 顺序 一 致 ， 但 也 可 能 不 完全 相同 ， 比 如 ， 表 中 的 LONG 字段 在 实际 行 数 据 中 一 般 被 放 在 
最 后 ， 实 际 的 列 顺序 在 col$ 表 的 segcol# 列 中 定义 。 
以 下 示例 中 的 行 数据 来 自 表 TEST， 结构 为 : 


Na me Null? Type 

C1 CHAR( 500) 

C2 CHAR( 100) 

C3 VARCHAR2(20) 


Linux 平台 : 小 端 ， 字 节 顺 序 需要 反 转 
Block: 83362 Offsets: 188 to 201 


00010700 ffff2000 21006902 5a04 
struct kdbh, 14 bytes 9188 数据 层 头 结构 
ubl kdbhflag 9188 0x00 (NONE) 
bl kdbhntab 9189 0x01 - - @4 1 个 表 的 数据 
b2 kdbhnrow @190 0x07 6040] 行 数据 
Sb2 kdbhfrre @192 Oxffff -- 行 索引 中 无 空闲 播 槽 
sb2 kdbhfsbo @194 0x0020 -- 空闲 空间 起 始 偏 移 
Sb2 kdbhfseo @196 0x0021 -- 空闲 空间 结束 偏 移 
b2 kdbhavsp 9198 0x0269 -- 空闲 空间 长 度 
b2 kdbhtosp 9200 0x045a -- 提交 后 空闲 空间 长 度 ° 


Block: 83362 Offsets: 202 to 205 


00000700 

struct kdbt[0], 4 bytes @202 REF] 
b2 kdbtoffs @202 0x0000 -- 在 行 索引 中 起 始 偏 移 
b2 kdbtnrow @204 0x0007 - - AAP RA] {6% Ж 


Block: 83362 Offsets: 206 to 219 


df0cd60c 7a04d90a dc08d308 2100 


sb2 kdbr[0] @206 0x0cdf -- £0 FF 
sb2 kdbr[1] @208 0x0cd6 $149 
sb2 kdbr[2] 9210 0x047a -- 第 2 行 
sb2 kdbr[3] @212 0x0ad9 $345 
sb2 kdbr[4] 9214 0x08dc $448 
sb2 kdbr[5] 9216 0x08d3 -- BS 行 
sb2 kdbr[ 6] @218 0x0021 -- $6 FF 


Block: 83362 Offsets: 221 to 726 
2c0001fe f4013720 20202020 20202020 
20202020 20202020 20202020 20202020 


20202020 20202020 20202020 20202020 

20202020 20202020 2020 

struct kdrh, 3 bytes 9221 第 6 行 数据 ， 偏 移 : 188433 = 221 
ubl kdrhflag @221 0x2c (KDRHFH, KDRHFF, KDRHFL) 
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bl kdrhlock @222 0x00 

bl kdrhccnt 9223 0x01 - - 包含 1 列 数 据 
[COL 1] 

Length 9224 fe f4 01 -- KR 500 

Data @227 3712020 . -- 值 : "7 


从 上 面 的 DUMP 信息 可 以 看 出 ， 如 果 行 数据 的 某 一 列 ( 假定 为 第 N 列 ) 后 面 的 所 有 列 取 值 
都 是 NULL， 那么 在 行 数据 中 只 需要 包含 N 列 的 数据 ，N+1 到 最 后 一 列 可 以 忽略 。 存 上 例 中 ， 只 
有 第 一 列 СІ 有 值 ， 后 面 的 C2、C3 列 都 无 值 ， 所 以 kdrhcent=1， 表 示 只 包含 一 列 的 数据 。 


9.4 解析 Oracle 字段 的 内 部 数据 存储 格式 


Oracle ^E Ek (J) 支持 的 数据 类 型 是 很 丰富 的 ， 既 可 以 是 简单 类 型 ， 也 可 以 是 复杂 类 型 ， 
比如 对 象 类 型 ARE, Oracle 支持 的 简单 类 型 主要 包括 以 下 几 种 。 
О 字符 串 类 型 : CHAR, NCHAR, VARCHAR? 和 NVARCHAR2。 
口 数值 类 型 : NUMBER 。 
口 二 进 制 类 型 : RAW。 
а 长 字符 串 类 型 LONG. 
а 长 二 进 制 类 型 LONG RAW. 
口 日 期 类 型 : DATE, 
а 时 间 惟 类 型 : TIMESTAMP, TIMESTAMP WITH TIME ZONE 和 TIMESTAMP WITH 
LOCALTIME ZONE。 
а 时 间 间 隔 类 型 : INTERVAL YEAR TO MONTH fil INTERVAL DAY TO SECOND. 
O 行 地 址 类 型 : ROWID fil UROWID, 

下 面 逐一 进行 介绍 。 

1. CHAR 

表示 固定 长 度 的 字符 串 ， 长 度 以 字 节 计数 ， 最 大 为 2000， 如 果 字 符 串 的 实际 长 度 小 于 所 和 定 
义 的 长 度 ， 则 尾部 用 空格 (0x20) 填充 ， 字 符 按 创建 数据 库 时 指定 的 字符 集 解 析 。 内 部 代码 为 
96。 


select dump(cast(' 12345' as char(10))) dump from dual 
DUMP 


Typ=96 Len=10: 49,50,51,52,53,32,32,32,32,32 


2. VARCHAR2 
表示 可 变 长 度 的 字符 串 ， 长 度 以 字 节 计数 ， 最 大 为 4000， 由 列 长 度 字 节 指 出 字符 串 的 实际 
长 度 ， 字 符 按 创建 数据 库 时 指定 的 字符 集 解析 。 内 部 代码 为 1。 


select dump(cast(' 12345' as varchar2(10))) dump from dual 
DUMP 


Тур=1 Len=5: 49,50,51,52,53 


一 
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3. NCHAR 
表示 固定 长 度 的 字符 串 ， 长 度 以 字符 计数 ， 最 大 为 2000， 如 果 字 符 串 的 实际 长 度 小 于 所 定 
义 的 长 度 ， 则 尾部 用 空格 填充 ， 字 符 按 创建 数据 库 时 指定 的 国家 字符 集 解析 。 内 部 代码 为 96。 


select dump(cast(' 12345' as nchar(10))) dump from dual 
DUMP 


Typ=96 Len=20: 0,49,0,50,0,51,0,52,0,53,0, 32,0, 32, 0, 32, 0, 32,0, 32 

4. NVARCHAR2 

表示 可 变 长 度 的 字符 串 ， 长 度 以 字符 计数 ， 最 大 为 4000， 由 列 长 度 字 节 指 出 字符 串 的 实际 
长 度 ， 字 符 按 创建 数据 库 时 指定 的 国家 字符 集 解析 。 内 部 代码 为 1。 


select dump(cast('12345' as nvarchar2(10))) dump from dual 
DUMP 


Тур=1 Len=10: 0,49,0,50,0,51,0,52,0,53 

5. NUMBER 

可 以 表示 整数 和 浮 点 数 ， 内 部 代码 为 2。 在 原理 上 采用 了 一 百 进 制 的 科学 计数 法 表示 数值 类 
型 的 数据 : 

aEn=a x 100^n 

Ж, a 为 有 效 数 据 ，1 友 Il<100; п, HRA. 

比如 ，100.1 按 这 种 方式 可 以 表示 为 1.0010 x 10041. 

具体 来 说 ，NUMBER 的 内 部 表示 由 3 部 分 组 成 : 

(1) 符号 位 和 帘 字 节 ， 该 字 节 包含 了 符号 位 和 知 信 息 ， 可 以 分 三 种 情况 处 理 。 
口 对 于 负数 ， 该 字 节 小 于 128, ЭЕ НЖг=255 - 字 节 - 128 - 65. 
а 对 于 正 数 ， 该 字 节 大 于 128, JF A= - 128 - 65。 
a 如 果 是 零 ， 那 么 该 字 节 等 于 128。 
(2) 有 效 数 字 ， 每 个 字 节 表 示 0 ~ 99 的 两 位 数字 ， 可 以 分 两 种 情况 处 理 。 
а 对 于 负数 ， 数 字 =101 -FH 
O 对 于 正 数 ， 数 字 = 字 节 - 1。 
(3) 元 余 字 节 ( 102 )， 只 有 负数 才 有 ， 用 于 内 部 排序 。 


select dump( 100.1) dump from dual 
DUMP 


Typz2 Len=4: 194,2,1,11 
select dump(-100.1) dump from dual 


Тур=2 Len=5: 61,100, 101,91, 102 


select dump(0) dump from dual 
DUMP 
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DUMP 


Typ=2 Len=3: 192,11,2 

6. DATE 

Ftd. 4E. H. H. BF. АЛ ВОИ ZO AE, ， 需 要 减 去 100 获得 实际 
的 值 ， 第 3、4 字 节 为 月 和 日 ， 最 后 3 个 字 市 表示 时 、 分 、 秒 ， 需 要 减 去 1 获得 实际 的 值 。 内 部 
代码 为 12。 


select dump(cast(to_date('20120101','YYYYMMDD') as date)) dump from dual 
DUMP 


Тур=12 Len=7: 120,112,1,1,1,1,1 


7. TIMESTAMP 

提供 了 比 秒 更 精确 的 时 间 值 ， 由 世纪 、 年 、 月 、 日 、 时 、 分 、 秒 和 小 数秒 ( 1/1000000000 ) 
组 成 。 前 7 个 字 节 和 DATE 一致， 后 4 个 字 节 表示 小 数秒 。 内 部 代码 为 180。 

create table test(ts timestamp) 

insert into test values(to ti mestamp(' 20120101 000000.001', YYYYMMDD HH24MISS.ff')); 


select dump(ts) dump from test 
DUMP 


Typ=180 Len=11: 120,112,1,1,1,1,1,0,15, 66, 64 


8. TIMESTAMP WITH TIME ZONE 

和 TIMESTAMP 类 似 , 不 过 增加 了 时 区 信息 。 最 后 两 位 分 别 表 示 时 区 小 时 和 时 区 分 钟 。 时 区 
小 时 需要 减 去 20 得 到 实际 的 值 ， 而 时 区 分 钟 需要 减 去 60 得 到 实际 的 值 。 内 部 代码 为 181。 

create table test(ts timestamp with time zone) 

insert into test values(to ti mestamp(' 20120101 000000.001', YYYYMMDD HH24MISS.ff')); 


select dump(ts) dump from test 
DUMP 


Тур=181 Len=13: 120,111,12,31,17,1,1,0,15,66,64,28,60 


9. TIMESTAMP WITH LOCAL TIME ZONE 

fll TIMESTAMP 类 似 , 但 是 隐 含 了 时 区 信息 , 实际 时 区 取 当 前 会 话 的 时 区 。 内 部 代码 为 231。 
create table test(ts timestamp with local time zone) 

insert into test values(to ti mestamp(' 20120101 000000.001', YYYYMMDD HH24MISS.ff')); 


select dump(ts) dump from test 
DUMP 


Тур=231 Len-11: 120,112,1,1,1,1,1,0,15, 66, 64 


10. RAW 
表示 可 变 长 度 的 二 进 制 学 节 串 ， 长 度 以 字 节 计数 ， 最 大 为 2000， 由 列 长 度 字 节 指 出 学 六 上 


pun 
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的 实际 长 度 。 内 部 代码 为 23。 


select dump(cast('3132333435' as raw(10))) dump from dual 
DUMP 


Typz23 Lenz5: 49,50,51,52,53 

11. LONG 

VARCHAR? 的 扩展 ， 表 示 可 变 长 度 的 字符 串 ， 长 度 以 字 节 计数 ， 最 大 可 达 2GB ， 由 列 长 度 
字 节 指出 字符 串 的 实际 长 度 ， 字 符 按 创建 数据 库 时 指定 的 字符 集 解 析 。 内 部 代码 为 8。 

12. LONG RAW 

RAW 的 扩展 ， 表 示 可 变 长 度 的 二 进 制 字 节 串 ， 长 度 以 字 节 计数 ， 最 大 可 达 2GB ， 由 列 长 度 
字 节 指出 字符 串 的 实际 长 度 。 内 部 代码 为 24。 

13. ROWID 

表示 行 数据 的 地 址 ， 主 要 有 两 种 类 型 : 

(1) 短 型 ( 受 限 型 )， 由 6 个 字 节 组 成 ， 前 4 个 字 节 为 数据 块 地 址 (DBA )， 后 2 个 字 节 表示 
位 于 块 中 的 第 几 行 。 内 部 代码 为 69。 

(2) 长 型 (扩展 型 )， 由 10 个 字 节 组 成 ， 前 4 个 字 节 为 对 象 的 段 标识 ， 紧 邻 的 4 个 字 节 为 数 
据 块 地 址 (DBA), Ja 2 个 字 节 表示 位 于 块 中 的 第 几 行 。 内 部 代码 为 69。 


select dump(cast(' AAAHZZAABAAAUW AAA' as rowid)) dump from dual 
DUMP 


Typ=69 Lenz10: 0,0,118,89,0,65,69,162,0,0 

14. UROWID 

通用 型 КОМІР”, 是 КОМІР 的 一 种 特殊 表示 形式 , 一 般 用 于 索引 组 织 表 和 外 部 表 。UROWID 
可 以 表示 З 种 不 同类 型 的 ROWID， 由 第 一 个 字 节 指明 。 内 部 代码 为 208。 不 同类 型 的 UROWID 
格式 不 同 ， 分 别 为 : 

(1) WEE ROWID, 由 4 位 对 象 标 识 、2 位 文件 号 、4 位 块 号 、2 位 行 号 构成 。 

(2) 逻辑 ROWID ， 由 可 选 的 DBA 、 行 号 以 及 必 选 的 主键 构成 。 

(3) 远程 ROWID ， 由 远程 数据 库 的 键 值 构成 。 


select dump(cast(' AAAHZZAABAAAUW AAA' as urowid)) dump from dual 
DUMP 


Typ=208 Lenz13: 1,0,0,118,89,0,1,0,1,69,162,0,0 

15. INTERVAL YEAR TO MONTH 

日 期 型 的 时 间 间 隔 ， 由 两 部 分 组 成 ， 前 4 个 字 节 为 年 份 的 间隔 ， 需 要 减 去 Ox80000000 获得 
实际 的 值 ， 后 1 个 字 节 为 月 份 的 间隔 ， 需 要 减 去 60 获得 实际 的 值 。 内 部 代码 为 182。 


select dump(cast('01-01' as interval year to month)) dump from dual 
DUMP 


Typz182 Len=5: 128,0,0,1,61 
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16. INTERVAL DAY TO SECOND 

时 间 型 的 时 间 间 隔 ， 由 3 部 分 组 成 ， 前 4 个 字 节 为 天 的 间隔 ， 需 要 减 去 0x80000000 获得 实 
际 的 值 ， 紧 临 的 3 个 字 节 分 别 为 时 、 分 、 秒 的 间隔 ， 需 要 减 去 60 获得 实际 的 值 。 最 后 4 个 字 节 
为 小 数秒 的 间隔 ， 需 要 减 去 0x80000000 获得 实际 的 值 。 内 部 代码 为 183。 


select dump(cast('01 01:01:01.01' as interval day to second)) dump from dual; 
DUMP 


Тур=183 Len-ll: 128,0,0,1,61,61,61,128,152,150,128 


行 链 、 行 迁移 为 什么 会 影响 访问 性 能 


在 执行 插入 或 更 改行 的 操作 时 , 由 于 块 的 空闲 空间 所 限 , 整 行 数据 可 能 无 法 完全 位 于 同一 块 
中 ,这 时 就 需要 将 该 行 数据 切割 成 多 个 分 片 ， 每 个 分 片 占 用 一 行 ,位 于 不 同 的 数据 块 ( 特殊 情况 
下 也 可 能 位 于 同一 个 块 )。 这 些 分 片 通过 内 部 指针 串 在 一 起 ， 组 成 一 个 完整 的 行 ， 并 且 用 第 一 个 
分 片 的 地 址 (ROWID ) 来 定位 该 行 ， 这 就 是 行 链 。 如 果 第 一 个 分 片 不 包含 任何 列 数据 ， 只 包含 
指向 下 一 个 分 片 的 指针 ， 这 种 情况 就 叫做 行 迁移 。 行 链 有 两 种 分 片 方式 : 一 种 方式 是 列 间 分 片 ， 
即 每 个 分 片 都 包含 一 个 或 多 个 完整 的 列 数据 ; 男 一 种 方式 是 列 内 分 片 ， 即 一 个 列 的 数据 被 分 割 成 
几 个 分 片 。 列 内 分 片 最 有 可 能 发 生 在 LONG FRE, FA LONG 字段 最 大 可 以 达到 2 GB, 单个 
数据 块 肯定 放 不 下 ， 所 以 需要 用 到 多 个 分 片 。Oracle 为 了 在 数据 结构 上 支持 分 片 ， 在 行头 后 面 增 
加 了 一 个 可 选 的 指针 字段 ,指向 下 一 个 分 片 ， 配合 标志 位 的 设置 ， 可 以 实现 分 片 的 串 接 。 这 个 指 
EFREN: 


DBA| 行 号 | 
e4ee Ф 
yep. 
O DBA 是 下 个 分 片 所 在 的 数据 块 地 址 ， 采 用 大 端 顺 序 表示 。 
а 行 号 表示 下 个 分 片 在 数据 块 中 位 于 第 几 行 ， 采 用 大 端 顺 序 表示 。 
下 面 介绍 行 迁移 的 实现 过 程 。 
а 第 一 个 分 片 的 行头 标志 字段 包含 KDRHEFH 和 KDRHFF 位 值 ， 行头 的 指针 指向 下 个 分 片 。 
最 后 一 个 分 片 的 行头 标志 字段 只 包含 KDRHFL 位 值 ， 无 行头 指针 。 
а 中 间 分 片 的 行头 标志 字段 无 KDRHFL fifi, 行头 的 指针 指向 下 个 分 片 。 
а 对 于 列 内 分 片 , 前 面 分 片 的 行头 标志 字段 包含 KDRHEN 位 值 , 行头 的 指针 指向 下 个 分 片 ， 
后 面 分 片 的 行头 标志 字段 包含 KDRHEP 位 值 。 
对 于 行 链 , 因为 第 一 个 分 片 是 空 的 , 所 以 第 一 个 分 片 的 行头 标志 字段 只 包含 KDRHFH 位 值 ， 
并 且 行 头 的 指针 指向 下 个 分 片 ， 而 第 二 个 分 片 的 行头 标志 字段 包含 了 KDRHFF 位 值 。 
以 下 示例 中 的 行 数据 来 自 表 TEST， 结 构 为 ; 
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Na me Null? Type 

C1 NUMBER 

C2 VARCHAR2( 4000) 
C3 LONG 

C4 DATE 


Li nux Фе: oS, ЗЭ ТОДА 33 
select dbms rowid.rowid block number(rowi d) 
block£é,dbms rowid.rowid row number(rowid) row# from test; 
- - 行 地 址 位 于 83363 块 的 第 0 行 
BLOCK# ROW# 


Block: 83363 Offsets: 4080 to 4091 


28010100 4145a200 0002c102 


struct kdrh, 9 bytes 94080 $1425: 83363 块 的 第 0 fr 
ubl kdrhflag 94080 0x28 (KDRHFH, KDRHFF) 
ubl kdrhlock 94081 0x01 
ubl kdrhccnt 94082 0x01 -- 8461 列 数据 
struct kd4ssrid kdrhnrid (4083 下 个 分 片 地 址 (标志 无 KDRHFL 位 值 ) 
krdba dba kd4ssrid (94083 0xa004145a2 --3& 83362 
kd sno sno kd4ssrid 94087 0x0000 -- $0 4r 
[COL 1] 表 TEST #1 列 : C1 
Length @4089 0x02 -- 长度 2 
Data @4090 cl 02 -- 值 : 1 


Block: 83362 Offsets: 193 to 216 


01020100 4145a400 000e4331 31313131 
31313131 31313131 


struct kdrh, 9 bytes 9193 第 2 个 分 片 : 83362 块 的 第 0 行 
ubl kdrhflag 9193 0x01 (KDRHFN) -- 最 后 1 列 被 分 片 
ubl kdrhlock @194 0x02 
ubl kdrhccnt @195 0x01 -- BH 1 Я] 
struct kd4ssrid kdrhnrid @196 下 个 分 片 地 址 (标志 无 KDRHFL 位 值 ) 
krdba dba_kd4ssrid @196 0ха004145а4 -- 3k 83364 
kd sno sno kd4ssrid 9200 0x0000 -- £0 行 
[COL 1] ATEST $2 Fl: C2 (ЖЖ, 
Length 9202 0x0e - -长度 : 14 
Data @203 43 31 . dk: *С1...' 


Block: 83364 Offsets: 195 to 314 


03020100 41454600 006e3131 31313131 
31313131 31313131 31313131 31313131 


31313131 31313131 


struct kdrh, 9 bytes 09195 3 ADH: 83364 块 的 第 0 £g 
ubl kdrhflag 9195 0x03 (KDRHFP,KDRHFN) -- 61 列 被 分 片 
ubl kdrhl ock 9196 0x02 


ubl kdrhccnt 9197 0x01 - -包含 1 列 
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struct kd4ssrid kdrhnrid @198 下 个 分 片 地 址 (标志 无 KDRHFL 位 值 ) 
krdba dba kd4ssrid 9198 0xa004145a6 -- 3k 83366 
kd sno sno_kd4ssrid @202 0x0000 -- #0 行 
[COL 1] ATEST $2 列 : C2 ( 紧 接 上 一 分 片 ， 未 完 ) 
Length @204 0x6e -- KH: 110 
Data @205 3131... sede: Up. ou! 


Block: 83366 Offsets: 195 to 4091 
03010300 414542500 00feb90e 31313131 
31313131 31313131 31313131 31313131 


31313131 31077870 01010101 01654333 
33333333 33333333 33333333 33333333 
33333333 33333333 33 


struct kdrh, 9 bytes 9195 第 4 个 分 片 : 83366 块 的 第 0 行 
ubl kdrhflag @195 0x03 (KDRHFP, KDRHFN) -- 最 后 1 列 被 分 片 
ubl kdrhlock @196 0x01 
ubl kdrhccnt 9197 0x03 -- 包含 3 Я] 
struct kd4ssrid kdrhnrid 9198 下 个 分 片 地 址 (标志 无 KDRHFL 位 值 ) 
krdba dba_kd4ssrid @198 0xa004145a5 --3k 83365 
kd sno sno kd4ssrid Q202 0x0000 -- #0 行 
[COL 1] ATEST 第 2 Я]: C2 ( 紧 接 上 一 分 片 ， 结 来) 
Length @204 fe b9 0e -- 长度: 3769 
Data 9207 31 31... -<+#:'1...' 
列 C2 由 3 个 分 片 组 成 ， 总 长 : 14411043769=3893 
[COL 2] 表 TE9T $4 列 : C4 (因为 第 3 $1C3 ALONG 字段 ， 实 际 存 
储 位 置 应 该 位 于 最 后 ， 所 以 原来 的 第 4 列 C4 被 交换 到 前 面 ) 
Length @3976 0x07 - -长度 : 7 
Data 93977 78 70 01 01 01 01 01 -- 4&: 2012-01-01 
[COL 3] ATEST $3 Я]: C3 ( KB) 
Length 93984 0x6b -- 长度: 107 
Data @3985 43 33 ... - 48: 'C3...' 


Block: 83365 Offsets: 193 to 4091 


060101fe 35013333 33333333 33333333 
33333333 33333333 33333333 33333333 


33333333 313333333 333333 


struct kdrh, 3 bytes @193 第 5 个 分 片 : 83366 块 的 第 0 行 
ubl kdrhflag @193 0x06 (KDRHFP, KDRHFL) -- 最 后 1 个 分 片 
ubl kdrhlock @194 0x01 
ubl kdrhccnt 9195 0x01 -- & 4&1 列 
[COL 1] ATEST 第 3 Я]: C3 ( 紧 接 上 一 分 片 ， 结 束 ) 
Length @196 fe 35 Of -- 长度: 3893 
Data @199 33 33 жы 14A: '33...' 


列 C3 由 2 个 分 片 组 成 ， 总 长 : 107+3893=4000 
对 于 行 链 或 行 迁移 , 因为 一 个 完整 的 行 数据 由 多 个 分 片 构成 , 这 些 分 片 很 可 能 位 于 不 同 的 数 
据 块 ， 因 此 , 在 访问 这 些 行 数据 时 ， 需 要 执行 多 个 逻辑 读 才 能 完成 一 行 数据 的 访问 。 另 外 ,对 于 
DML 操作 ， 除 了 第 一 个 分 片 外 ， 涉 及 修改 的 其 他 分 片 也 都 需要 加 行 锁 ， 这 些 附加 的 ITL 操作 极 
大 地 影响 了 性 能 。 


95 理解 LOB 的 存储 结构 241 


9.5 理解 LOB 的 存储 结构 


大 对 象 数据 类 型 (LOB ) 是 从 Oracle 8 开始 出 现 的 ， 分 为 内 部 存储 LOB 和 外 部 存储 LOB, 
内 部 存储 LOB 可 以 保存 二 进 制 数 据 (BLOB ) 或 字符 数据 ( CLOB 和 NCLOB )。 外 部 存储 LOB 
(BFILE) 比较 特殊 ， 具 体 的 数据 保存 在 操作 系统 文件 中 ， 而 文件 路 径 被 保存 为 BFILE 列 值 。 在 
LOB 出 现 之 前 , 大 数据 只 能 使 用 LONG 或 LONGRAW 字段 保存 , 但 是 LONG 或 LONGRAW 类 
型 存在 以 下 缺陷 。 

а 需要 和 行 数据 一 起 保存 ， 这 样 不 仅 增 加 了 段 的 长 度 ， 并 且 容 易 形 成 行 链接 ， 加 大 了 表 的 
访问 成 本 。 

о 最 大 长 度 限 制 为 2 СВ. 

口 在 一 个 表 中 只 能 有 一 个 LONG 字段 。 

а 字符 集 必须 和 数据 库 的 本 地 字符 集 一 致 。 

а 只 能 作为 一 个 整体 被 读 取 到 内 存 或 转 储 到 文件 中 才能 对 其 内 容 进行 操作 ， 很 不 方便 。 

与 LONG 字段 相 比 ，LOB 有 以 下 优势 。 

a 数据 存放 灵活 ， 既 可 以 保存 在 行 中 (不 得 超过 4000 B )， 也 可 以 保存 在 单独 的 LOB 段 中 。 
о 从 Oracle 10g 版 本 开始 ， 最 大 长 度 可 以 达到 2 ~ 128 TB (9i 版 本 限制 为 4 GB )。 

口 在 一 个 表 中 可 以 有 多 个 LOB 字段 。 

а 字符 集 采 用 UNICODE ， 可 以 支持 多 国字 符 。 

O 支持 随机 访问 ， 可 以 采用 类 似 文件 流 的 方式 对 其 内 容 进 行 定位 和 操作 ， 很 方便 。 

LOB 数据 有 两 种 保存 方式 ， 如 果 数 据 量 比较 小 ( 实际 数据 + UIT RI 4000 B )， 可 以 直接 
保存 在 行 中 ; 如 果 数 据 量 比较 大 , 或 者 在 定义 LOB 列 时 ， 明 确 指定 保存 在 行 外 ， 那么 LOB 将 被 
保存 在 单独 的 LOB 段 中 。 不 管 是 在 行 中 还 是 在 LOB 段 中 ， 都 要 用 到 LOB 定位 器 ， 这 是 LOB 最 
重要 的 数据 结构 ,保存 了 LOB 的 信息 ， 其 结构 kolbl 如 下 : 


e e eI Re e e 4e M4 eI e + 
|0-1| 231] 4 | 5 6 7 | $9 [10-19] 20- | 
e e 4e e +- e ГЕ eI M 4e + 
| KA| 版 本 | 标志 1 | 标志 2| 保留 | 保留 | 字符 宽度 | 标识 | 1- NODE | 
to e ТГ +- +- +- 4e +- ТГ + 


下 面 分 别 介绍 每 项 的 含义 。 
О KÆ (len) 表示 定位 器 的 长 度 ， 一 般 固 定 为 0x54， 不 同 于 实际 长 度 。 
O 标志 1 (lobflgl ) 主要 包括 以 下 几 种 取 值 : 


KOLBLBLOB 0х00000001 // BLOB 
KOLBLCLOB 0х00000002 // CLOB 


O 标志 2 Clobflg2 ) 由 一 些 位 值 组 合 而 成 ( OR 操作 )， 这 些 位 值 主要 包括 : 


KOLBLI DX 0x00000004 // 包含 | - NODE 
KOLBLI NI 0x00000008 // 定位 器 已 初始 化 


O 字符 宽度 (bytelen ) 表 示 LOB 数据 使 用 的 字符 集 的 字 节 长 度 , 一 般 为 2 UNICODE 字符 )。 
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O 标识 Clobid ) 是 该 LOB 的 主键 。 


о I-NODE 包含 了 LOB 数据 的 存储 信息 ， 它 在 定位 器 中 是 可 选 的 字段 ， 如 果 标 志 2 设置 了 


KOLBLIDX, 那么 该 字段 就 在 在， 否则 就 不 存在 。 一 般 而 言 ， 如 果 LOB 列 在 定义 时 包含 
了 行内 存储 (enable strorageinrow ) 选项 ， 在 定位 器 中 就 会 包含 LNODE; 而 如 果 包 含 了 
行 外 存储 (disable strorage in row ) 选项 ， 在 定位 器 中 就 不 会 包含 LNODE ， 这 时 I-NODE 


包含 在 第 一 个 LOB 索引 项 中 。 
接 下 来 ， 我 们 来 分 析 INODE 的 数据 结构 kdlinode: 


e e e e eI eI ee + 
| 01| 2 | 3 | rq 89 | 10-15 | 16- | 
e 4e e e 4e 4e e + 
| K| 标志 | 保留 | 块 数 | 字 节 数 | 版 本 | 数据 | 
e e e e eI eI e + 


每 项 的 含义 如 下 所 示 。 
О 长 度 (size kdlinode ) 表示 整个 LNODE 的 长 度 (包括 数据 )。 
O 标志 (flag_kdlinode ) 由 一 些 位 值 组 合 而 成 ( OR 操作 )， 这 些 位 值 主要 包括 : 


KDLI DI NI 0x00000001 |] LOB A X 

KDLI DI DX 0x00000002 11 1- NODE 位 于 L0B 索引 中 
KDLI DDBA 0x00000004 |] 包含 数据 是 CHUNK 的 块 地 址 
KDLI DDAT 0x00000008 |]. 包含 数据 是 实际 的 列 值 


О HK (blocks_kdlinode ) 是 LOB 数据 所 占用 的 完整 CHUNK 数 。 


口 数据 是 可 选 字段 ， 根 据 标志 的 取 值 解读 其 意义 ， 它 可 能 有 以 下 几 种 情况 。 
a 包含 实际 的 数据 ， 数 据 的 长 度 为 NODE 长 度 - 16。 


О 字 节 数 ( bytes_kdlinode ) 是 LOB 数据 在 占用 的 最 后 一 个 不 完整 CHUNK 中 实际 使 用 的 字 


m 包含 CHUNK 的 块 地 址 (DBA )， 每 个 块 地 址 需要 4 个 字 节 ， 因 此 实际 包含 的 CHUNK 


数 为 LNODE 长 度 -16)/4 ， 最 多 可 以 包含 12 个 CHUNK 的 块 地 址 。 


对 于 包含 大 量 CHUNK 的 LOB 数据 , 不 可 能 把 它 的 所 有 CHUNK 块 地 址 都 放 在 I-NODE 中 ， 
因此 Oracle 又 设计 了 LOB 索引 这 样 的 结构 ,用 来 存放 所 有 CHUNK 的 地 址 ,LOB 索引 的 键 为 LOB 


标识 + CHUNK 号 ， 一 个 索引 项 最 多 可 以 存放 8 个 CUHNK 的 地 址 。 


LOB 段 是 以 CHUNK 为 单位 组 织 数 据 的， 每 个 CHUNK 是 一 组 连续 的 数据 块 ， 如 果 修 改 了 


CHUNK 中 的 数据 ， 即 使 是 一 个 字 节 ， 也 会 生成 一 个 新 的 CHUNK, ， 原 来 的 CHUNK 作为 | 


日 版 本 


被 保存 ， 以 支持 一 致 性 读 操 作 。 为 了 限制 CHUNK 所 有 旧版 本 占用 的 空间 数量 ， 在 创建 LOB 列 
时 , 可 以 设置 一 个 阔 值 , 一 旦 超出 该 阔 值 ,最早 的 一 些 旧 版 本 会 被 删除 。 这 样 , 在 访问 旧版 本 时 ， 


就 可 能 导致 ORA-01555 错误 。 


LOB 数据 结构 (定位 器 和 INODE ) 的 字 节 顺序 和 前 面 提 到 的 一 些 数据 结构 不 同 ， 它 与 平台 
无 关 ， 统 一 采用 大 端 字 节 顺 序 。 另 外 ，CLOB 列 中 的 字符 数据 使 用 的 字符 集 可 以 支持 多 国字 符 ， 


在 不 同 的 版 本 中 存在 一 些 区 别 ， 见 表 9-1。 
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表 9-1 
cH s i CLOB/NCLOB 内 部 存储 
DB 版 本 平台 字 节 顺序 DB 兼容 性 模式 - š: 
LOB (永久 性 ) 临时 LOB 
Oracle 8.1.x, 9.0.x, | 大 端 或 小 端 >8.0 UCS2 UCS2 
9.2.x 版 本 大 端 或 小 端 8.0 不 允许 UCS2 
K m (AIX. HP, | 不 限 (10g 中 最 低 模 
Solaris ) 式 是 92) AL16UTF16 AL16UTF16 
92312 
Oracle 10g 及 以 上 бб ae TR UCS2 ALIGUTFI6 
小 端 (Windows, Linux) ` - 
新 建 的 表 | AL16UTF16 | AL16UTF16 
9.2 UCS2 AL16UTF16 


从 10g 版 本 开始 ，CLOB 列 和 NCLOB 都 使 用 AL16UTF16 字符 集 。 这 个 字符 集 和 平台 无 关 ， 
每 个 字符 是 一 个 双 字 节 (WORD )， 采 用 大 端 表 示 。 而 在 & 或 % 版 本 中 ， 使 用 的 则 是 UCS2， 这 
个 字符 集 和 平台 有 关 ， 由 平台 决定 双 字 节 字 符 的 大 、 小 端 。 


Na me Null? Type 
C1 NUMBER 
C2 CLOB 


Linux 平台 : 小 端 ， 数 据 库 版 本 为 9. 2 ， 因 此 CL0B 字符 集 采 用 UC52 ， 也 是 小 痛 ， 需 要 反 转 
Block: 83362 Offsets: 4049 to 4091 

2c010202 c1022400 54000102 0c800000 

02000000 01000000 004fb100 10090000 

00000000 00000000 000000 


struct kdrh, 3 bytes 94049 
ubl kdrhflag 94049 0x2c (KDRHFH, KDRHFF, KDRHFL) 
ubl kdrhlock 94050 0x01 
ubl kdrhcent 94051 0x02 -- 包含 2 я] 
[COL 1] 
Length @4052 0x02 -- 长度: 2 
Date @4053 cl 02 -- ff: 1 
[COL 2] 
Length @4055 0x24 -- KE: 36 
struct kolb @4056 值 为 定位 器 
ub2 len @4056 0x0054 
ub2 version @4058 0x0001 
ubl lobflgl 94060 0x02 (KOLBLCLOB) 
ubl 100#192 94061 0x0c (KOLBLIDX, KOLBLI NI) 
ubl lobflg3 94062 0x80 
ubl lobflg4 4063 0x00 
ub2 bytelen 94064 0x0002 
ubl lobi d[ 10] 4066 00 00 00 01 00 00 00 00 4f bl 
struct kdlinode 
ub2 size kdlinode 94076 0x0010 --|-NODE K£ 16 
ubl flag kdlinode 94078 0x09 (KDLIDI NI, KDLI DDAT) 


ubl future kdlinode 94079 0x00 
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kdl page block kdlinode 
k blk bytes kdlinode 

kdl vn version kdlinode 
该 L0B 无 实际 数据 ， 是 由 empty_cl0b() 产生 的 


Block: 83362 Offsets: 3996 to 4048 
2c020202 c1032e00 54000102 0c800000 
02000000 01000000 004fb200 1a090000 
00000000 0a000000 00000131 00320033 


00340035 00 

struct kdrh, 3 bytes 
ubl kdrhflag 
ubl kdrhlock 
ubl kdrhccnt 


[COL 1] 
Length 
Date 

[COL 2] 
Length 
struct 

ub2 
ub2 
ubl 
ubl 
ubl 
ubl 
ub2 
ubl 


struct kdl 


kol b 
en 
version 
obflgl 
obflg2 
obflg3 
obflg4 
bytelen 
obi d[10] 
i node 


ub2 size kdlinode 

ubl flag kdlinode 

ubl future kdlinode 
kdl page block kdlinode 
k blk bytes kdlinode 
kdl vn version kdlinode 


Data 


# LOB 实际 数据 为 : 1 12345" 


Block: 83362 Offsets: 3949 to 3995 
2c010202 c1042800 54000102 0c800000 
02000000 01000000 004fe300 14050000 
0000000f a0000000 00000200 4145b4 


struct kdrh, 3 bytes 
ubl kdrhflag 
ubl kdrhlock 
ubl kdrhccnt 


[COL 1] 
Length 
Date 

[COL 2] 
Length 
struct 


kol bl 


94080 
94084 
94086 


03996 
03996 
03997 
03998 


03999 
@4000 


94002 
94003 
94003 
94005 
94007 
94008 
94009 
84010 
84011 
84013 


94023 
94025 
94026 
84027 
84031 
04033 
@4039 


@3949 
@3949 
@3950 
@3951 


@3952 
@3953 


03955 
03956 


0х00000000 
0х0000 
0х0000. 00. 00. 00, 00 


0x2c (KDRHFH, KDRHFF, KDRHFL) 
0x02 


0x02 -- 包含 2 Я] 
0x02 -- КЖ 2 
cl 03 -- 值 : 2 
0х2е -- 长度: 46 
值 为 定位 器 

0x0054 

0x0001 


0x02 (KOLBLCLOB) 

0x0c (KOLBLIDX, KOLBLI NI 

0x80 

0x00 

0x0002 

00 00 00 01 00 00 00 00 4f b2 


0x001a --I- NODE 6 26 

0x09 (KDLIDINI, KDLI DDAT) 
0x00 

0x00000000 

0x000a 

0x0000.00.00.00.01 

31 00 32 00 33 00 34 00 35 00 


0x2c (KDRHFH, KDRHFF, KDRHFL) 
0x01 


0x02 -包含 2 5| 
0x02 长度: 2 
cl 04 ddl 3 
0x28 -- KA: 40 
值 为 定位 器 
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ub2 len @3956 0x0054 
ub2 version 93958 0x0001 
ubl lobflgl 93960 0x02 (KOLBLCLOB 
ubl lobflg?2 93961 0x0c (KOLBLIDX, KOLBLI NI 
ubl lobflg3 93962 0x80 
ubl lobflg4 93963 0x00 
ub2 bytelen 93964 0x0002 
ubl lobi d[ 10] 93966 00 00 00 01 00 00 00 00 4f e3 
struct kdlinode 
ub2 size kdlinode 93976 0x0014 --1- NODE 长 度 20 
ubl flag_kdlinode @3978 0x05 (KDLIDINI, KDLI DDBA) 
ubl future kdlinode 93979 0x00 
kdl page block kdlinode 93980 0x00000000 
k blk bytes kdlinode 93984 0x0fa0  -- 最 后 一 个 CHUNK 62 4000 58 
kdlvn version_kdlinode @3986 0x0000.00.00.00.02 
Data @3992 00 41 45 b4 --CHUNK 的 块 地 址 


ik LOB 实际 数据 位 于 块 83380 (LOB FR) , &2 2000 个 字符 (4000 字 节 ) ， 实 际 数据 如 下 : 
Block: 83380 Offsets: 56 to 4055 


58005800 58005800 58005800 58005800 X.X. X. X. X. X. X. X. 


58005800 58005800 58005800 58005800 X.X. X.X. X.X. X. X. 


LOB 字段 的 优化 


通过 以 上 对 LOB 字段 存储 结构 的 介绍 ， 我 们 可 以 总 结 出 以 下 一 些 有 用 的 经 验 。 

口 如 果 应 用 在 查询 表 时 ，LOB 列 和 其 他 列 是 分 开 访 问 的 ,可 以 考虑 将 所 有 的 LOB 列 数据 保 
存在 LOB 段 ， 也 就 是 设置 行 外 存储 ( disable strorage in row ) 选项 。 

O 如 果 LOB 列 的 绝 大 部 分 数据 比较 大 ， 可 以 设置 较 大 的 CHUNK. 

O 如 果 LOB 列 被 频繁 访问 ， 可 以 考虑 把 它 缓 存 到 DB Cache 中 。 默 认 情 况 下 ，LOB 是 不 被 
缓存 的 ， 需 要 通过 设置 CACHE 选项 打开 ，CACHE 也 可 以 细 分 为 缓存 读 写 和 只 缓存 读 。 
口 在 不 影响 业务 的 情况 下 尽 可 能 设置 较 小 的 版 本 阔 值 和 保留 期 限 ， 以 避免 过 多 的 空间 浪费 。 
а 对 于 需要 在 LOB 字段 上 频繁 执行 一 系列 小 的 读 写 操作 的 应 用 ， 可 以 使 用 LOB Buffering 
Subsystem， 它 会 在 客户 端 缓 存 、 批 量 修 改 LOB 字段 的 内 容 。 

a 尽 可 能 采用 随机 访问 特性 访问 特定 位 置 的 内 容 ， 而 不 是 所 有 内 容 。 

о 在 查询 语句 中 ， 慎 用 “*” 通 配 符 选择 所 有 列 ， 只 访问 应 用 需要 用 到 的 列 。 


理解 表 的 结构 


表 是 我 们 最 常见 的 对 象 ， 也 是 数据 库 中 最 为 重要 的 对 象 。 不 过 很 多 工作 多 年 的 DBA 仍然 不 
太 了 解 表 到 底 是 什么 。 在 本 章 中 ,， 老 白 将 为 大 家 “扫盲 ”， 通 过 介绍 表 的 内 部 存储 结构 ， 帮 助 大 
家 更 加 深入 地 了 解 表 存储 优化 方面 的 一 些 技巧 。 
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在 本 节 中 ， 我 们 要 学 习 的 内 容 是 “ 表 ”。Oracle 数据 库 是 一 种 关系 型 数据 库 ， 在 关系 型 数据 
库 里 ,一 组 关系 的 实体 化 就 可 以 组 成 一 张 表 。 表 包含 一 个 或 者 多 个 字段 ， 这 些 字 段 按照 某 种 规则 
(我 们 称 为 关系 ) 组 成 一 个 集合 ， 每 个 关系 就 称 为 一 行 数据 ， 也 就 是 我 们 常 说 的 一 条 记录 。 实 际 
上 ,只 要 有 了 关系 型 数据 库 的 概念 ， 那么 就 不 难 理解 表 、 记 录 、 关 系 之 类 的 术语 了 。 表 是 Oracle 
数据 库 中 十 分 重要 的 对 象 ，DBA 的 主要 工作 就 是 和 不 同 的 表 和 数据 打交道 。 

Oracle 中 的 表 是 怎么 存储 的 呢 ? 想 要 弄 清 这 个 问题 , 就 需要 学 习 一 些 Oracle 数据 存储 的 基本 
概念 。 首 先 要 了 解 什么 是 块 (block), Ht Oracle 访问 的 最 小 物理 单位 Oracle 数据 库 中 块 的 大 
小 一 般 是 2 ~ 32 KB Oracle 的 块 大 小 和 操作 系统 的 块 大 小 是 不 同 的 ， 前 者 往往 远大 于 后 者 ， 
此 ，Oracle 的 块 不 是 基本 的 VO 单位 ， 而 只 是 Oracle 的 基本 访问 单位 。 对 于 Oracle 来 说 ， 每 个 表 
空间 都 有 唯一 的 块 大 小 , 在 Oracle 8i 或 者 更 早 版 本 的 数据 库 中 , 整个 数据 库 的 所 有 表 空 间 都 有 唯 
一 的 块 大 小 。 从 Oracle 9i 开始 ,不 同 的 表 空 间 可 以 拥有 不 同 的 块 大 小 ,因此 参数 DB_BLOCK SIZE 
定义 的 就 不 再 是 数据 库 块 大 小 ， 而 是 默认 为 表 空 间 块 大 小 。 

虽然 块 是 Oracle 的 最 小 访问 单位 , 但 是 由 于 块 太 小 了 , 如 果 表 的 存储 数据 按照 块 来 分 配 , 那 
么 效率 就 太 低 了 。 这 里 继续 介绍 一 个 更 大 的 单位 一 一 EXTENT， 中 文 可 以 翻译 成 扩展 ,一 个 扩展 
是 由 一 组 连续 的 块 组 成 的 。 扩展 是 Oracle 最 小 的 分 配 单位 ，Oracle 在 给 对 象 分 配 空间 时 ,最 少 分 
配 一 个 扩展 。 每 个 扩展 是 由 一 个 或 者 多 个 连续 的 块 组 成 的 。 这 种 连续 是 指 文 件 上 的 连续 , 在 目前 
存储 技术 充分 使 用 条 带 化 技术 的 前 提 下 , 这 是 一 种 逻辑 上 的 连续 , 但 在 物理 磁盘 上 并 不 一 定 就 是 
连续 的 。 

比 扩展 更 大 的 单位 是 段 (segment ), 一 组 结构 相同 的 扩展 就 组 成 了 一 个 段 。 最 常见 的 段 包括 
表 、 索 引 、 表 分 区 、 索 引 分 区 、 回 滚 段 等 。 段 存储 在 某 个 表 空 间 中 ， 表 空间 是 个 逻辑 的 概念 ， 一 
个 表 空 间 一 般 包含 一 个 或 者 多 个 数据 文件 ， 当 然 也 可 以 不 包含 任何 文件 , 这 样 的 表 空 间 是 不 能 使 
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用 的 。 Scbs E, 段 是 存储 在 数据 文件 里 的 , 但 是 这 种 存储 是 按照 表 空 间 来 组 织 的 。 一 个 段 可 能 存 
储 在 一 个 数据 文件 中 ,也 可 能 存储 在 多 个 数据 文件 中 ,不 过 这 些 数据 文件 必须 属于 同一 个 表 空间 。 
图 10-1 是 一 个 很 好 的 逻辑 示意 图 。 


Oracle 行 > 


图 10-1 


ЖЕ Oracle 数据 库 中 就 是 存储 在 段 里 的 。 一 张 普通 的 表 就 对 应 一 个 段 ， 不 过 还 有 一 些 特 例 : 
а 一 张 索引 组 织 表 可 能 包含 了 多 个 段 ， 比 如 OVERFLOW Pto 
a 在 一 张 表 中 ,如 果 有 LOB 字段 ，LOB 字段 可 能 存储 在 独立 的 段 中 , 那么 这 张 表 就 可 能 
含 多 个 段 。 
a 一 张 分 区 表 可 能 存储 在 多 个 独立 的 段 中 ， 这 些 段 甚至 可 能 存储 在 不 同 的 表 空 间 中 。 
О 在 一 个 复 (cluster) 中 ,可 能 存储 多 张 表 , 而 不 是 一 张 表 。 因 此 对 于 存储 于 簇 中 的 表 来 说 ， 
表 和 段 不 是 一 一 对 应 的 。 

通过 上 面 的 介绍 ， 大 家 知道 了 表 的 数据 实际 上 是 以 “ 段 ” 的 形式 存储 在 表 空 间 里 的 。 当 创建 
一 个 表 的 时 候 ，Oracle 会 自动 为 这 张 表 创 建 段 ， 并 分 配 第 一 个 扩展 。 我 们 已 经 知道 了 每 个 扩展 是 
由 多 个 连续 的 块 组 成 的 ,数据 就 存储 在 这 些 块 中 。 当 这 些 块 都 使 用 完了 ,那么 下 一 次 需要 插入 数 
据 的 时 候 , Oracle 就 会 自动 为 这 张 表 增加 一 个 扩展 。 随 着 数据 量 的 增长 , 这 张 表 也 在 不 断 地 增 大 。 
一 张 表 中 扩展 的 数量 受到 表 空 间 容 量 和 MAXEXTENTS 参数 的 限制 。 对 于 早期 版 本 的 数据 库 ， 
MAXEXTENTS 的 默认 值 是 2355， 在 这 种 情况 下 ， 某 些 较 大 的 表 很 容易 就 会 达到 MAXEXTENTS 
的 极限 ， 这 个 时 候 再 插入 数据 ， 可 能 就 会 出 现 ORA-01631: Max # Extents (%s) Reached in TABLE 
%s.%s 错误 信息 。 这 时 ， 就 必须 要 加 大 MAXEXTENTS 参数 了 。 

在 了 解 了 表 和 段 后, 下 面 来 分 析 表 的 内 部 。 我 们 知道 表 中 的 数据 是 存储 在 块 里 的 , 那么 块 的 
结构 是 什么 样 的 呢 ? 


248 第 10 章 理解 表 的 结构 


实际 上 ， 在 一 个 块 中 ,块头 存储 了 一 些 数据 块 的 信息 、SCN、 事 务 槽 等 信息 ， 尾 部 的 4 个 字 
TERE, 块 尾 存在 的 目的 是 为 了 和 块头 的 数据 进行 校 验 , 确保 这 个 数据 块 是 一 致 的 ( 具体 的 算 
法 对 于 大 多 数 人 来 说 是 不 需要 了 解 的 ， 大 家 可 以 和 完 放 一 放 ， 在 今后 的 进 阶 内 容 中 再 学 习 )。 块 头 
和 块 尾 中 间 的 部 分 就 是 存储 的 数据 ， 如 图 10-2 所 示 。 表 中 的 数据 是 从 数据 块 的 底部 开始 存储 的 ， 
比如 ， 某 个 块 中 存储 了 3 条 记录 , 那么 第 一 条 记录 的 尾部 正好 和 块 尾 相 接 ,存储 在 块 的 最 后 ,第 
三 条 记录 存储 在 靠近 块头 的 地 方 , 前面 就 是 这 个 块 的 空闲 空间 。 随 着 数据 块 中 数据 的 增长 , 数据 
区 域 逐 渐 接近 块头 的 位 置 , 块 中 空闲 的 部 分 越 来 越 少 。 如 果 这 个 块 的 空闲 空间 不 足以 插入 一 条 新 
记录 了 ， 系统 就 会 寻找 别 的 可 以 插入 数据 的 块 ; 如 果 所 有 的 数据 块 都 已 经 满 了 , 那么 系统 就 会 增 
加 一 个 新 的 扩展 。 表 中 的 空闲 块 管理 ， 是 个 十 分 复杂 的 话题 ， 我 们 将 在 后 面 专门 讨论 ,对 此 还 有 
疑问 的 朋友 ， 就 完 收 起 这 个 疑问 ,继续 学 习 其 他 的 内 容 吧 。Oracle 的 知识 点 相当 广 ， 而 且 关联 性 
十 分 强 ， 在 学 习 的 时 候 ， 不 一 定 非 要 一 次 性 把 所 有 的 知识 点 都 搞 清楚 ， 循 序 渐进 才 是 最 关键 的 ， 
请 大 家 不 要 心急 。 


块头 


空闲 空间 


行 数据 


图 10-2 


现在 的 表 中 都 设计 了 大 量 的 VARCHAR 字段 ，VARCHAR 字段 使 用 起 来 十 分 灵活 ， 而 且 不 
会 浪费 空间 。 不 过 ，VARCHAR 字段 的 使 用 也 给 块 中 的 数据 重组 带 来 了 麻烦 。 比 如 ， 在 一 张 包含 
VARCHAR 字段 的 表 中 插入 一 条 数据 的 时 候 ， 如 果 首 先 插入 了 某 个 字段 的 1 个 字 节 ,而 后 来 通过 
UPDATE 将 这 个 字段 的 值 修改 为 200 个 字 节 , 那么 这 条 记录 就 需要 重组 ,从 而 导致 整个 块 进行 重 
组 。 而 如果 此 时 修改 的 这 条 记录 所 在 的 块 已 经 没有 200 个 空闲 的 字 节 了 , 那么 这 条 记录 修改 后 就 
无 法 存储 在 这 个 块 中 。Oracle 在 处 理 这 种 情况 的 时 候 , 会 把 这 条 记录 整个 迁移 到 另外 一 个 存在 足 
够 空闲 空间 的 数据 块 中 ,而 在 原来 记录 的 地 方 登记 一 个 指向 新 位 置 的 指针 ,这 种 情况 就 是 我 们 常 
说 的 行 链 。 行 链 的 产生 ， 会 加 大 系统 的 开销 ， 影 响 数据 访问 的 性 能 。 

前 面 我 们 介绍 了 很 多 的 技术 细节 ,可 能 有 些 人 已 经 氏 昏 欲 睡 了 。 实际 上 , 下 面 的 内 容 才 是 我 
们 要 学 习 的 精华 。 对 于 一 张 表 , 我 们 在 设计 的 时 候 要 注意 些 什 么 呢 ?” 从 上 述 关于 段 的 知识 中 , 我 
们 可 以 得 到 以 下 的 结论 。 

在 创建 表 时 , 选择 合适 的 扩展 大 小 是 十 分 重要 的 。 过 小 的 扩展 会 导致 系统 不 断 增 加 扩展 的 数 


a 
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量 ， 从 而 影响 大 数据 量 搬入 的 性 能 ,这 对 于 存在 大 量 并 发 搬入 的 系统 尤为 重要 。 不 过 也 不 需要 过 
于 担心 扩展 大 小 所 带 来 的 性 能 问题 , 这 里 讨论 的 性 能 下 降 可 能 只 是 千 分 之 一 , 甚至 更 小 , 实际 上 ， 
一 个 段 拥 有 小 于 1024 个 扩展 对 于 段 的 访问 性 能 影响 很 小 。 

下 一 个 问题 就 是 表 空 间 碎片 的 问题 。 由 于 表 空 间 中 表 的 扩展 大 小 不 同 , 因此 在 使 用 一 段 时 间 
后 ， 表 空间 就 会 出 现 不 连续 的 现象 ， 在 扩展 之 间 会 出 现 一 些 “ 洞 "， 这 种 情况 我 们 一 般 叫 做 表 空 
间 碎 片 。 一 些 经 验 丰 富 的 DBA 总 是 告诫 别 人 , 注意 整理 表 空间 碎片 ， 否 则 会 影响 数据 库 的 性 能 。 
实际 上 ， 从 根本 上 来 说 ， 表 空间 碎片 最 大 的 危害 是 浪费 了 空间 ， 而 不 是 影响 了 性 能 。 所 有 的 数据 
访问 都 会 在 有 效 的 扩展 中 进行 , 根本 不 会 去 扫描 碎片 所 在 的 数据 块 , 所 以 认定 表 空 间 碎片 会 影响 
性 能 是 一 种 以 认 传 话 的 观点 。 
事实 上 ， 对 于 表 的 参数 定义 来 说 ,设置 合理 的 PCTFREE 值 比 减少 表 空间 碎片 重要 得 多 。 在 
老 白 碰 到 的 客户 中 , 能 够 根据 表 和 业务 的 特点 来 设计 PCTFREE 的 少 之 又 少 。 不 合理 的 PCTFREE 
可 能 导致 大 量 行 链 的 出 现 ， 从 而 影响 访问 性 能 。 

在 创建 表 的 时 候 ， 还 有 一 个 十 分 重要 的 参数 一 一 INITRANS ， 这 个 参数 指定 了 初始 化 事务 村 
的 数量 。 事 务 模 是 一 个 非常 重要 的 对 象 , 每 个 事务 在 修改 某 个 数据 块 时 ， 都 需要 在 这 个 数据 块 中 
分 配 一 个 事务 槽 。 如 果 当 前 没有 空闲 的 事务 槽 ， 就 需要 动态 扩展 一 个 ,每 个 事务 槽 需要 24B。 讲 
FIBA, KAA НД А Oracle 为 什么 要 从 底部 向 顶 部 分 配 空间 了 , 因为 事务 档 是 从 项 部 向 底 
部 分 配 空间 的 ,这 样 两 种 分 配方 式 才 不 会 产生 冲突 。 一 般 情 况 下 ,默认 的 事务 槽 参数 并 不 会 带 来 
明显 的 性 能 问题 ， 不 过 对 于 一 些 并 发 修改 较 大 的 表 ， 如 果 PCTFREE 参数 设置 过 低 ， 就 会 导致 事 
务 槽 扩展 的 时 候 无 法 分 配 空间 , 从 而 导致 事务 等 待 事务 槽 。 我 们 可 以 通过 下 列 脚本 来 检查 系统 中 
哪些 表 产 生 了 较为 严重 的 事务 槽 等 待 。 

set line 132 

col statistic name format a30 trunc 

SELECT t. OWNER, t.0BJ ECT NAME, t.0BJECT TYPE, STATISTIC NAME, t.VALUE value 

FROM v$segment statistics t 


WHERE t. STATISTIC NAME = 'ITL waits' 
AND t. VALUE > 10 order by value 


如 果 我 们 通过 上 面 的 查询 发 现 了 事务 槽 等 待 较为 严重 的 段 ， 那 么 就 需要 考虑 对 这 些 段 增加 
INITRANS 参数 值 。 不 过 由 于 这 里 查询 到 的 值 是 数据 库 启动 以 来 总 的 统计 值 ， 因 此 需要 在 一 个 时 
间 段 中 多 次 执行 这 个 SQL， 才 能 判断 某 个 段 是 否 真 的 经 常 出 现 ITL 等 待 。 在 修改 INTRANS & 
数 的 时 候 , 我 们 也 要 注意 , 一 旦 修改 了 这 个 参数 ,对 应 段 中 新 增 的 数据 块 会 增加 初始 化 事务 槽 的 
数量 ， 而 旧 的 数据 块 是 不 会 改变 的 ， 如 果 要 彻底 解决 问题 ， 还 需要 对 这 个 段 进 行 一 次 重组 。 


10.1.1 PCTFREE 和 行 链 


上 一 节 介 绍 了 表 的 基本 结构 ， 从 表 的 存储 结构 上 讨论 了 几 个 建 表 的 参数 。 实 际 上 , 在 许多 项 
目 中 ， 开 发 团队 并 没有 对 表 进 行 合理 的 设计 ， 从 而 导致 系统 上 线 后 出 现 大 量 的 性 能 问题 。 

一 个 最 常见 的 问题 就 是 行 链 和 行 迁 移 。 行 链 的 出 现在 绝 大 多 数 系统 中 是 由 于 设计 不 合理 造成 
的 ， 比 如 , 某 张 表 的 行 长 度 超过 了 一 个 数据 块 的 大 小 , 那么 这 个 表 的 部 分 行 就 会 出 现行 链 。 这 种 
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行 链 实际 上 是 由 于 设计 者 选择 了 不 合理 的 数据 块 大 小 所 导致 的 。 从 Oracle 9i 开始, 不 同 的 表 空间 
可 以 使 用 不 同 的 块 大 小 ， 因 此 我 们 完全 可 以 设计 块 大 小 较 大 的 表 空间 来 存放 这 些 表 。 

有 些 行 链 是 不 可 避免 的 ,而 绝 大 多 数 的 行 迁移 是 可 以 避免 的 。 行 迁移 是 怎么 产生 的 呢 ? Oracle 
数据 库 支 持 VARCHAR 字段 ，VARCHAR 字段 的 使 用 极为 灵活 ， 正 是 这 种 灵活 性 导致 了 行 迁 移 
的 产生 ,在 创建 一 张 表 的 时 候 , 我 们 一 般 不 太 会 关注 PCTFREE 这 个 参数 ,该 参数 的 默认 值 是 10%, 
其 含义 是 ， 当 某 个 数据 块 的 使 用 率 小 于 “100% - PCTFREE” 时 ,这 个 数据 块 是 可 以 插入 数据 的 ， 
一 旦 块 使 用 率 达 到 了 这 个 指标 ,这 个 数据 块 就 不 能 再 插入 数据 了 。Oracle 预 留 这 部 分 空间 的 目的 
就 是 为 VARCAHR 字段 的 扩展 提供 空间 。 大 家 是 不 是 还 记得 , Oracle 的 数据 块 是 从 块 的 底部 开始 
使 用 的 ， 空 闲 空间 在 块头 和 数据 之 间 。 

下 面 通过 一 个 示例 来 说 明 表 数据 的 存储 。 首 先 创建 一 张 测 试 表 ， 并 且 搬 和 三 条 记录 : 


create table test1 ( а integer,b varchar2(100),c varchar2(100)); 


insert into testl values (1,null,'aaaa'); 
insert into test1 values (2,null,'bbbb'); 
insert into test1 values (1,' 11111',null); 
commit; 


然后 查找 这 个 扩展 所 在 的 位 置 : 


SQL» select extent id,file id,block id from dba extents where ѕедтепі пате =' TESTI 
AND OWNER-z'SCOTT' 


EXTENT ID FILE ID BLOCK ID 


这 里 ， 先 查找 10 号 文件 是 什么 : 
SQL»select file name from dba data files where file_id=10 


FILE. NAME 


lopt/oracle/oradata/orcl/users02. dbf 

下 面 通过 dd 命令 将 499 这 个 数据 块 转 储 ( dump ) ШЖ: 

dd ifz/opt/oracle/oradata/orcl/usersO02.dbf of=a.dmp bs=8192 skipz501 count=1 

上 述 命令 从 文件 中 复制 出 了 第 501 号 块 , 这 个 块 就 是 存储 这 三 条 记录 的 数据 块 , 该 数据 块 的 
尾部 如 图 10-3 所 示 。 


00001f80h: 35 38 37 35 2C 00 03 05 C4 03 4B 3B 4B OB 62 20 ; 5875,...?K; K.b 

00001f90h: 30 30 32 37 34 35 38 37 34 08 64 32 37 34 35 38 ; 002745874.027458 
DODOifaDÜh: 37 34 2С 00 03 05 C4 03 4B ЗВ 4А OB 62 20 30 30 ; 74,...?K;J.b DD 
DOOO0ifbÜh: 32 37 34 35 38 37 33 08 64 32 37 34 35 38 37 33 ; 2745873.d2745873 
DOOO0ifcOh: 2С 00 03 05 C4 03 4B 3B 49 OB 62 20 30 30 32 37 ; ,...?K;I.b 0027 
DOOOifdOÜh: 34 35 38 37 32 08 64 32 2C 01 02 02 C1 02 05 31 ; 45872.d2,...7.1 
O00001£fe0h: 31 31 31 31 2С 01 03 02 C1 03 FF 04 62 62 62 62 ; 1111,...?  .bbbb 
DODO1ffOh: 2С O1 03 02 Ci 02 FF D4 61 61 61 61 01 06 06 F7 ; ,...? ааа. ..0 
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其 中 ，2c 01 03 02 cl 02 FF 04 61 61 61 61 就 是 我 们 插入 的 第 一 条 记录 (l. null, “aaaa'), 2c 
是 行头 ， 这 是 一 个 标准 的 数据 行 ，01 表示 该 行使 用 了 1 号 ITL FE, 03 表示 这 一 条 记录 共有 多 少 
个 字段 ( 本 例 有 3 个 字段 )。02 Cl 02 是 第 一 个 字段 的 值 ， 这 个 字段 是 数值 类 型 02 表示 该 字段 
WKE, C1 02 就 是 十 进 制 的 1。 后 面 的 FF 表示 第 二 个 字段 是 空 值 ， 而 04 61 61 61 61 是 最 后 一 
个 字段 aaaa。 从 第 三 条 记录 来 看 ( 三 条 中 最 上 面 的 那 条 记录 ， 地址 是 00001fdoh， 以 2C 01 02 FF 
头 )， 可 知 每 一 行 的 第 三 个 字 节 表示 这 一 行 的 字段 数量 。 为 什么 这 一 行 只 有 两 个 字段 呢 ?” 我 们 来 
看 前 面 的 insert 语句 ， 这 一 条 记录 的 最 后 一 个 字段 是 NULL， 如 果 某 一 行 的 最 后 几 个 字段 都 是 
NULL, ЯА Oracle 在 存储 时 ， 就 会 直接 省 略 这 些 NULL 的 字段 ， 以 节约 存储 空间 。 

在 这 种 情况 下 ， 如 果 我 们 执行 “UPDATE TEST1 SET B= ‘ABC’ WHERE A=1” 语 句 , 会 出 
现 什么 情况 呢 ? 这 时 数据 块 会 被 重组 , 在 第 一 条 记录 中 原本 只 有 一 个 字 节 “FF” 的 地 方 插入 三 个 
字 节 ， 同 时 这 个 数据 块 的 数据 占用 的 顶部 也 上 升 了 。 

从 上 面 的 例子 我 们 可 以 看 出 ,一旦 VARCHAR 字段 发 生 改变 ， 就 需要 在 数据 块 中 额外 分 配 
空间 。 因 此 , 在 更 新 某 条 记录 的 时 候 ， 如 果 系 统 发 现 这 个 数据 块 已 经 满 了 ， 就 无 法 在 原 有 的 数据 
块 中 存储 这 条 记录 了 ,那么 这 条 记录 就 被 迫 迁 移 到 别 的 数据 块 中 。 而 在 这 条 记录 原本 存放 的 位 置 ， 
会 被 放 入 一 个 指针 。 在 这 种 情况 下 ， 如 果 要 访问 这 条 记录 ， 就 需要 在 读 取 了 这 个 指针 后 ， 再 访问 
另外 一 个 数据 块 , 行 迁移 的 存在 降低 了 数据 访问 的 性 能 。 也 许 有 朋友 要 问 ， 为 什么 原来 的 行 迁 移 
走 了 还 留 下 一 个 指针 ? 不 留 指针 不 就 不 存在 这 个 性 能 隐患 吗 ? 我 们 可 能 忘记 了 一 点 , 也 许 这 张 表 
存在 几 个 索引 ,如 果 我 们 将 这 一 行 直 接 迁 移 而 不 留 指针 , 那么 所 有 索引 中 和 这 一 行 相 关 的 数据 都 
需要 进行 重组 ， 这 个 重组 的 代价 远 高 于 行 迁移 访问 的 开销 。 

下 面 我 们 做 一 个 实验 ， 首 先 对 这 张 表 插入 一 定 的 数据 ， 为 了 证 明 在 某 些 情况 下 使 用 默认 为 
10% 的 PCTFREE 参数 是 多 么 危险 , 这 里 将 表 的 PCTFREE 参数 设置 为 10%, 然后 TRUNCATE 原 
有 的 表 ， 重 新 插入 数据 : 


drop sequence seqt 

create sequence seqt 

alter table testl pctfree 10 
truncate table test1l; 


begin 
for i in 1..1000 loop 
insert into testl values (seqt.nextval,'abc', null); 
end loop; 
end; 
I 
commit; 


这 时 执行 查询 语句 : 


SQL» select a,b fromtestl where а=1 


1 abc 
Execution Plan 
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Plan hash value: 4122059633 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Ti me 
| 0 | SELECT STATEMENT | | 2 | 12 | 2 (0) | 00:00:01 | 
|* 1]| TABLE ACCESS FULL| TESTI | 2 | 12 | 2 (0)| 00:00:01 | 


1 - filter("A"=1) 
Statistics 

1 recursive calls 
0 db block gets 
8 consistent gets 
0 physical reads 
0 redo size 

459 bytes sent via SQL*Net to client 

400 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
1 rows processed 


由 于 并 未 创建 索引 , 所 以 这 个 查询 进行 了 全 表 扫 描 , 产 生 了 8 个 CR GET。 下 面 通过 UPDATE 
字段 使 数据 块 产生 行 迁移 : 
update testl set c='123456789012345678901234567890abcdefghg'; commit 


这 时 ， 我 们 再 来 看 数据 块 中 发 生 了 什么 ， 如 图 10-4 所 示 。 


00001b00h: O6 20 02 00 02 80 01 F? 00 05 2c 02 03 02 C1 2E ; . ...€.2.,...? 
DODOibiO0h: 03 61 62 63 27 31 32 33 34 35 36 37 38 39 30 31 ; .abc'12345678901 
DODOOibzÜh: 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 ; 2345678901234567 
DOOO01530h: 38 39 30 61 62 63 64 65 66 67 68 67 BE ; 890abcdefgholmmm 
00001b40h: Б # иаа 2 02 OO 02 80 01 F? OO 03 20 02 ; $8.2. . 
DoO01550h: 00 02 80 01 F? OO 02 20 02 00 02 80 01 F? OO 01; ..€.2. ...€.2?. 
DoO01560h: 20 02 OO 02 80 01 F? 00 00 20 02 00 02 80 01 F6 ; ...€.2. ...€.? 
DOoO01570h: 01 C4 20 02 00 02 80 01 Еб 01 C3 20 02 00 02 80 ; .2...€.22...€ 
00001580): 01 F6 O1 C2 20 02 00 OZ 80 01 F6 01 C1 20 02 DO ; .22...€.22.. 
00001b90h: 02 80 01 F6 01 CO 20 OZ 00 OZ 80 01 F6 01 BF 20 ; .€.22...€.?? 
OO00015baO0h: 02 00 02 80 01 F6 01 BE 20 02 OO 02 80 01 F6 01 ; ...€.?2...€.? 
OoO0001bbOh: BD 20 02 00 02 80 01 F6 01 BC 20 02 OO 02 80 01 ; ?...€.22...€. 
oO0001bcOh: F6 01 BB 20 02 OO 02 80 01 F6 01 Bà 20 02 OO OZ ; ?2...€.?2... 
oO0001bdOh: 80 01 F6 01 ВЭ 20 02 OO 02 80 01 F6 01 BS 20 OZ ; €.?2...€.2?. 
00001ребһ: OO 02 80 01 F6 01 B7 20 OZ OO 02 80 01 F6 01 B6 ; ..€.2?...€.?? 
O0000ibf0h: 20 02 OO 02 80 01 F6 01 BS 20 02 OO 02 80 01 F6 ; ...€.?22...€.? 


00001с00)Һ: 01 B4 20 02 OO 02 80 01 F6 01 ВЗ ZO 02 OO 02 80 ; .2...€.2?...€ 
00001с10Һ: 01 F6 01 B2 2С 02 03 02 C1 15 03 61 62 63 27 31 ; .??...?.арс'1 
00001с20Һ: 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 ; 2345678901234567 
00001c30h: 38 39 30 31 32 33 34 35 36 37 38 39 30 61 62 63 ; 8901234567890abc 
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可 以 看 到 ， 部 分 原来 的 数据 行 变 成 了 一 些 类 似 于 20 02 00 02 80 01 f7 00 04 这 样 的 数据 ， 这 
说 明 发 生 了 行 迁移 ， 这 一 行 已 经 被 迁移 到 RDBA=0x028001f7 的 数据 块 中 的 0x04 行 中 了 。 这 时 ， 
如 果 访 问 这 条 数据 ， 就 需要 再 到 0x028001f7 做 一 次 查询 才能 完成 。 我 们 再 来 执行 刚才 的 select 
语句 ， 看 看 发 生 了 什么 变化 : 

SQL> set autotrace on; 

SQL» col b format a50 trunc 


SQL» set line 132 
SQL» select a,b from test1 where а=1 


Plan hash value: 4122059633 


| id Operation | Name | Rows | Bytes | Cost (%CPU)| Ti me | 
| 0 | SELECT STATEMENT | | 2 | 12 | 2 (0)| 00: 00: 01 
|* 1 TABLE ACCESS FULL| TEST1 | 2 | 12 | 2 (0) | 00:00:01 | 


1 - filter("A"=1 
Statistics 
0 recursive calls 
0 db block gets 
17 consistent gets 

0 physical reads 
0 redo size 

459 bytes sent via SQL*Net to client 

400 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
1 rows processed 


我 们 看 到 由 于 行 迁移 , 原本 的 8 个 CR GET ÆR T 177 CR GET, 看 样子 行 迁移 的 负面 作用 
还 是 挺 明显 的 。 当 然 这 是 个 特例 ， 做 了 全 表 扫 描 ， 但 是 行 迁移 会 产生 负面 影响 是 肯定 的 。 

了 解 了 行 迁 移 的 产生 原因 以 及 危害 性 后 ,我 们 再 回 过 头 来 认真 考虑 一 让 PCTFREE 这 个 参数 。 
这 时 就 会 发 现 , 这 样 一 个 小 参数 ,里 面 却 包含 了 数据 库 优 化 的 大 道理 。 如 果 一 张 表 中 的 数据 被 插 
人 后 经 常 需要 进行 更 新 ， 那么 必须 要 把 PCTFREE 参数 设置 得 大 一 些 ， 以 避免 行 迁移 的 出 现 。 如 
果 一 张 表 在 插入 数据 后 不 做 修改 和 删除 ， 那 么 是 不 是 就 可 以 把 PCTFREE 参数 设置 得 小 一 些 ， 比 
如 5， 甚 至 更 小 ， 这 样 的 话 这 张 表 的 每 一 个 数据 块 中 就 可 以 包含 更 多 的 记录 ， 从 而 减少 访问 这 张 
表 带 来 的 开销 。 而 如 果 有 一 张 表 ， 数 据 块 的 热 块 冲突 很 严重 ， 是 否 也 可 以 通过 加 大 PCTFREE & 
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数 来 减少 每 个 数据 块 中 的 记录 数 ， 从 而 缓解 热 块 冲突 呢 ?” 实 际 上 , 减少 热 块 冲突 更 好 的 办 法 是 将 
这 张 表 放 在 BLOCK SIZE 较 小 的 表 空 间 里 ， 不 过 在 实际 生产 环境 中 往往 难以 实现 ， 当 发 现 热 块 
冲突 存在 的 时 候 ， 只 能 通过 权宜 之 计 来 解决 问题 了 。 

在 调整 PCTFREE 参数 时 ,要 注意 的 是 ,由 于 这 个 参数 是 可 以 动态 调整 的 ,因此 调整 PCTFREE 
参数 只 能 对 新 的 数据 插入 起 作用 , 而 对 于 已 经 填充 过 满 的 旧 数 据 块 是 无 法 生效 的 。 要 想 彻底 解决 
行 迁 移 的 问题 ， 必 须 在 调整 该 参数 后 ， 对 表 进 行 重组 ， 这 样 才能 对 表 中 的 所 有 数据 块 都 起 作用 。 
重组 表 的 方法 有 很 多 ， 比 如 ALTER TABLE ... MOVE 或 者 EXP/IMP。 


10.1.2 ”那些 逝去 的 老 参 数 


有 几 个 参数 随 着 Oracle 数 据 库 版 本 的 变化 逐渐 逝去 了 ,不 过 这 些 参数 可 能 承载 了 很 多 老 DBA 
的 荣誉 和 苦 泪 ,它们 是 PCTUSED FREELISTS #1 FREELIST GROUPS。 随 着 ASSM ( 自动 段 空 
间 管 理 ) 在 Oracle 9i 版 本 的 推出 ， 现 在 的 新 数据 库 已 经 很 少 使 用 MSSM ( 手工 段 空间 管理 ) To 
自动 段 空 间 管理 和 手工 段 空 间 管理 最 大 的 区 别 在 于 空闲 块 的 管理 。 在 自动 段 空 间 管理 出 现 之 前 ， 
Oracle 的 空闲 块 是 通过 FREELIST 机 制 来 管理 的 ， 在 创建 表 和 索引 时 必须 指定 PCTFREE、 
PCTUSED FREELISTS , FREELIST GROUPS 等 参数 。 数据 块 经 过 格式 化 后 会 被 挂 在 FREELIST 
E, 这 样 需要 插入 数据 的 前 台 进 程 就 可 以 在 FREELIST 上 找到 可 以 插入 数据 库 的 块 , 并 插入 相关 
的 数据 。 数 据 插 入 后 ， 如 果 数 据 块 中 的 空闲 空间 比例 小 于 PCTFREE 参数 指定 的 比例 ， 那 么 这 个 
数据 块 就 不 能 再 次 插 和 人 数据 了 ， 该 数据 块 将 被 系统 从 FREELIST 上 摘除 ,下 次 插入 数据 时 ， 就 会 
重信 到 其 他 的 数据 块 中 。 如 果 这 个 数据 块 中 的 某 些 数据 被 删除 后 ,空闲 空间 低 于 PCTUSED 参数 
的 指标 ， 那 么 该 数据 块 将 会 再 次 被 放 到 FREELIST 上 ， 这 样 这 个 数据 块 就 可 以 再 次 插入 数据 了 。 
有 人 可 能 会 产生 疑问 , 一 个 比较 “ 满 ”的 数据 块 , 如 果 删 除了 数据 , 不 就 马上 可 以 插入 数据 了 吗 ? 
这 时 只 要 将 其 放 回 FREELIST 不 就 行 了 ， 还 用 PCTUSED 参数 干什么 呢 ? 实际 上 ，Oracle 的 这 个 
设计 是 十 分 优秀 的 ， 如 果 不 设计 PCTUSED 这 个 参数 ,我 们 会 碰 到 这 样 的 情况 : 一 个 数据 块 刚刚 
插入 数据 后 被 系统 从 FREELIST 中 摘除 ， 马 上 又 因为 删除 数据 被 再 次 放 入 FREELIST， 那么 就 可 
能 产生 抖动 ，FREELIST 的 性 能 就 会 因为 频繁 重组 而 急剧 下 降 。 

同样 的 道理 , 在 一 个 MSSM 管理 的 段 中 , 如 果 PCTFREE 和 PCTUSED 这 两 个 参数 设置 得 不 
合理 ， 那 么 这 种 抖动 现象 还 会 出 现 。 比 如 ,设置 PCTFREE 为 30，PCTUSED 为 65 ， 如 果 行 长 度 
较 大 的 话 , 一 个 数据 块 在 刚刚 插入 一 条 记录 后 又 马上 删除 了 两 三 条 记录 ,在 这 种 情况 下 ,这 个 数 
据 块 可 能 会 出 现 刚 刚 被 系统 从 FREELIST 上 摘除 ， 就 马上 又 被 再 次 放 入 FREELIST 的 现象 。 从 
MSSM 管理 空闲 块 的 方法 ,可 以 看 出 设置 合理 的 PCTUSED 参数 的 重要 性 。 如 果 PCTUSED 参数 
设置 得 过 高 ， 可 能 会 导致 FREELIST 的 抖动 ; 而 如 果 PCTUSED 参数 设置 得 过 低 ， 可 能 又 会 导致 
数据 块 中 存储 的 记录 数 过 少 ， 这 两 种 情况 都 会 影响 全 表 扫 描 操 作 的 性 能 。 

讨论 完 PCTUSED 参数 ,我们 再 来 分 析 男 外 一 个 重要 的 段 空间 管理 参数 一 一 FREELISTS。 
FREELISTS 用 于 存放 可 插入 数据 的 数据 块 ， 它 存在 于 永久 数据 段 、 临 时 数据 段 、 索 引 段 和 回 深 
Beh, 一 个 段 中 可 以 包含 三 种 类 型 的 FREELISTS: MASTER FREELISTS , PROCESS FREELISTS 


= 
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fil TRANSACTION FREELISTS 。 

每 个 段 中 只 有 一 个 MASTER FREELISTS， 它 在 段 创建 的 时 候 就 生成 了 ， 段 中 高 水 位 以 下 的 
空闲 块 都 挂 在 MASTER FREELISTS 上 。 当 某 个 前 台 进 程 需 要 插入 数据 时 ， 就 可 以 到 MASTER 
FREELISTS 上 去 查找 空 闻 块 ， 查找 操作 从 FREELISTS 的 头 部 开始 ， 直 到 找到 可 以 插入 数据 的 块 
为 止 。 

明 眼 人 看 到 这 里 马上 就 会 发 现 问题 ，FREELISTS 是 一 个 串 行 的 结构 ， 如 果 有 大 量 并 发 的 会 
话 需 要 插入 数据 ，FREELISTS 就 会 成 为 瓶颈 。 实 际 上 Oracle 对 此 早 有 对 策 ， 在 Oracle 中 还 存在 
另外 一 种 FREELISTS , 即 PROCESS FREELISTS .PROCESS FREELISTS 和 MASTER FREELISTS 
构成 一 种 主 从 协同 机 制 ， 每 个 PROCESS FREELISTS 上 都 链接 了 一 组 空闲 块 ， 这 些 空闲 块 是 从 
MASTER FREELISTS 上 摘 取 的 ， 前 台 进 程 要 插入 数据 时 ， 首 先 必须 锁定 一 个 PROCESS 
FREELISTS ， 然 后 从 这 个 PROCESS FREELISTS 上 查找 一 个 空闲 的 数据 块 用 于 插入 数据 。 当 
PROCESS FREELISTS 上 没有 可 用 的 空闲 块 时 ， 会 锁定 MASTER FREELISTS， 从 中 分 配 一 组 空 
闲 块 到 PROCESS FREELISTS 上 ， 然 后 再 从 PROCESS FREELISTS 上 分 配 空闲 的 空间 。 这 听 起 
来 似乎 很 不 错 ，Oracle 的 这 种 设计 避免 了 FREELISTS 成 为 并 行 插 入 操作 的 瓶 诺 ， 不 过 大 家 要 注 
意 的 是 ，Oracle 默认 的 FREELISTS 参数 值 是 1， 此 时 段 头 中 只 有 一 个 MASTER FREELISTS ， 而 
不 存在 PROCESS FREELISTS 。 

不 幸 的 是 , 绝 大 多 数 用 户 在 使 用 MSSM 的 时 候 并 没有 设置 FREELISTS 参数 ,也 并 没有 留意 
到 这 种 设置 带 来 的 负面 影响 。 这 种 负面 影响 到 底 有 多 大 呢 ? 老 白 遇 到 过 的 最 为 极端 的 案例 是 某 移 
动 公司 的 短信 平台 。 这 个 平台 每 天 需要 插入 的 数据 量 在 几 千 万 条 记录 到 几 亿 条 记录 之 间 , 由 于 使 
用 的 是 Oracle 8i 数 据 库 ， 因 此 只 能 采用 MSSM。 我 们 在 这 个 平台 上 进行 了 测试 ， 在 存在 8 个 并 
发 插入 进程 的 情况 下 ,如果 将 FREELISTS 设置 为 8, 性 能 比 FREELISTS 设置 为 1 时 提高 了 5.7%。 
在 一 般 情况 下 , 性 能 可 能 提升 没有 这 么 明显 , 但 如 果 FREELISTS 参数 设置 得 不 合理 , 造成 1% ~ 
5% 的 性 能 影响 还 是 很 有 可 能 的 。 

FREELISTS 机 制 设计 得 确实 比较 巧妙 ， 似 乎 所 有 的 问题 都 已 经 解决 了 。 不 过 细心 的 读者 还 
会 有 一 些 疑问 ， 那 些 已 经 标志 为 “ 满 ” 的 块 怎么 再 次 回 到 FREELISTS 上 呢 ? 难道 只 要 数据 被 删 
除了 ， 块 使 用 率 低 于 PCTUSED 参数 值 了 ， 这 个 数据 块 就 会 马上 被 放 到 FREELISTS 上 吗 ? 这么 
做 似乎 也 不 太 稳妥 ， 因 为 一 旦 删除 操作 回 滚 了 ,那么 岂 不 是 又 要 再 次 把 这 个 块 从 FREELISTS 上 
摘除 吗 ?” 实际 上 ，Oracle 早 就 为 这 种 操作 设计 了 算法 ， 那 就 是 TRANSACTION FREELISTS。 一 
个 段 默 认 有 16 个 TRANSACTION FREELISTS ， 如 果 某 个 事务 要 修改 这 个 段 ， 首 先 会 搜索 
TRANSACTION FREELISTS。 如 果 找 到 了 这 个 会 话 的 TRANSACTION FREELISTS , 那么 就 继续 
使 用 ; 否则 这 个 会 话 就 会 继续 查找 空闲 的 槽 位 。 如 果 找 不 到 空闲 的 槽 位 ， 这 个 会 话 就 会 试图 去 扩 
展 一 个 新 的 TRANSACTION FREELISTS ， 在 扩展 时 ， 如 果 段 头 中 正好 已 经 没有 空闲 空间 了 ， 那 
么 这 个 会 话 就 只 能 等 待 其 他 会 话 提交 后 腾 出 空闲 的 槽 位 ,这 种 等 待 类 似 于 前 面 章 节 介绍 过 的 事务 
槽 等 待 , 不 过 事务 槽 等 待产 生 于 数据 块 中 , 而 TRANSACTION FREELISTS 等 待 则 存在 于 段 头 中 。 
如 果 使 用 MSSM 时 ， 段 头 的 等 待 较为 严重 ， 我 们 就 应 该 检查 一 下 是 否 是 这 个 原因 引起 了 等 待 。 

假设 一 个 会 话 申请 到 TRANSACTION FREELISTS 后 在 某 个 数据 块 中 删除 了 一 些 数据 , 那么 
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在 这 个 数据 块 的 使 用 率 低 于 PCTUSED 参数 值 后 ， 该 数据 块 就 会 被 挂 到 TRANSACTION 
FREELISTS 上 ， 此 时 这 个 数据 块 就 可 以 被 插入 数据 了 。 不 过 由 于 这 个 数据 块 只 是 在 本 会 话 的 
TRANSACTION FREELISTS 上 ， 因 此 在 事务 提交 之 前 ， 只 有 本 事务 可 以 在 这 个 数据 块 中 插入 数 
据 ， 只 有 等 事务 提交 后 ，TRANSACTION FREELISTS 上 的 数据 块 才 会 被 挂 到 MASTER 
FREELISTS 的 尾部 ， 这 时 其 他 的 会 话 才 可 以 使 用 这 些 空闲 块 。 

上 述 算 法 是 不 是 很 巧妙 ? Oracle 通过 这 三 种 FREELISTS ， 很 好 地 解决 了 插 人 数据 时 的 性 能 
问题 ， 将 FREELISTS 机 制 产 生 瓶 颈 的 可 能 性 降 到 了 最 低 。 

对 于 MSSM 来 说 ， 还 有 一 个 十 分 重要 的 参数 FREELIST GROUPS。 一 般 来 说 ， 这 个 参数 被 
认为 是 OPS/RAC 相关 的 参数 ， 实 际 上 这 种 认识 存在 一 定 的 片面 性 ， 不 过 我 们 还 是 先 从 这 个 参数 
在 RAC 环境 下 的 应 用 说 起 。 对 于 КАС 系统 来 说 ， 在 MSSM 环境 下 ，FREELISTS 的 算法 和 单 实 
例 环境 是 十 分 类 似 的 , 了解 CACHE FUSION 机 制 的 读者 这 时 就 会 担心 了 , 这 种 机 制 可 能 在 RAC 
环境 下 产生 严重 的 全 局 缓存 相关 的 性 能 问题 。 比 如 ， 不 同 的 实例 都 对 某 张 表 进 行 插入 ， 如 果 
Instance 1 上 有 一 个 会 话 在 BLOCK 10 中 插入 了 一 条 记录 ， 然 后 Instance 2 上 也 有 一 个 会 话 在 
BLOCK 10 中 插入 了 另外 一 条 记录 ， 接 着 ，Instance 1 再 次 在 BLOCK 10 中 插入 记录 ， 这 样 的 操 
作 如 果 很 多 的 话 ， 就 会 成 为 一 场 灾难 ， 这 个 数据 块 将 在 两 个 节点 中 不 停 地 来 回 传播 ， 形 成 了 
GLOBAL BUFFER BUSY, 一 旦 这 种 数据 块 变 多 ， 那 么 整个 RAC 系统 的 性 能 就 会 急剧 恶化 。 

事实 上 ，Oracle 有 相应 的 技术 来 避免 这 种 悲剧 的 发 生 ，FREELIST GROUPS 就 是 为 解决 这 个 
问题 而 设计 的 。 比 如 , 目前 的 RAC 环境 是 一 个 两 实例 的 数据 库 。 我 们 对 某 张 表 设 置 了 FREELIST 
GROUPS 参数 为 2, 那么 这 张 表 创建 完毕 后 ,在 这 张 表 的 段 头 中 会 有 两 个 块 ， 专门 用 于 存储 两 组 
不 同 的 FREELISTS ( 我们 称 之 为 FREELISTS BLOCK )。 这 种 情况 下 ， 段 头 数据 块 里 只 有 一 个 
SUPER MASTER FREELISTS， 上 面 挂 载 了 这 个 段 中 的 空闲 块 ， 而 在 每 个 FREELISTS BLOCK 中 
都 有 一 个 MASTER FREELISTS 和 若干 个 PROCESS FREELISTS( 由 参数 FREELISTS 参数 确定 ), 
在 这 两 组 FREELISTS 上 分 别 挂 了 一 组 空闲 块 ， 当 某 个 实例 上 的 会 话 需 要 插入 数据 的 时 候 ， 会 通 
过 Instance ID, PID, Instance 数量 、FREELIST GROUPS 参数 等 因素 来 选择 一 组 FREELISTS, 
并 从 这 组 FREELISTS 上 选取 空闲 块 。 只 要 设置 FREELIST GROUPS 的 值 等 于 Instance 的 数量 ， 
就 可 以 确保 每 个 实例 都 有 自己 独立 的 FREELISTS 组 ， 由 于 一 个 数据 块 只 能 挂 载 在 一 个 
FREELISTS 上 , 这样 就 确保 了 不 同 实例 插入 数据 时 ,不 会 选择 不 同 的 数据 块 ( FREELIST GROUPS 
的 值 大 于 Instance 数量 时 ， 一般 也 可 以 确保 在 大 多 数 情 况 下 不 会 出 现 不 同 实 例 共享 相同 
FREELISTS 组 的 情况 ， 由 于 其 选择 算法 较为 复杂 ， 这 里 不 做 详细 讨论 )。 

这 种 机 制 很 好 地 避免 了 我 们 所 担心 的 问题 , 这 是 不 是 很 棒 呢 ? 但 不 幸 的 是 , 我 在 十 多 年 的 优 
化 工作 中 ， 还 没有 碰 到 过 一 套 为 RAC 环境 设置 了 FREELIST GROUPS 参数 的 系统 ， 所 有 的 系统 
都 是 采用 默认 值 ， 而 Oracle 的 默认 值 恰 恰 是 每 个 段 只 有 一 个 FREELISTS 组 。 更 为 不 幸 的 是 ， 一 
且 段 创建 之 后 ，FREELIST GROUPS 就 是 固定 的 ， 无 法 动态 地 扩展 ， 如 果 要 扩展 FREELIST 
GROUPS, ， 就 必须 对 整个 段 进行 重建 。 因 此 ， 在 做 数据 字典 设计 的 时 候 ， 开 发 人 员 应 该 事先 为 
RAC 环境 设计 好 FREELIST GROUPS 参数 ， 以 避免 今后 扩展 带 来 的 麻烦 。 在 设置 FREELIST 
GROUPS 参数 时 ， 我 们 不 仅仅 要 考虑 到 RAC 环境 ， 而 且 要 为 今后 RAC 节点 的 扩展 预 留 足 够 的 
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FREELIST GROUPS, 

看 到 这 里 ,读者 应 该 理解 了 FREELIST GROUPS 在 RAC 应 用 中 的 作用 ,而 事实 上 ,FREELIST 
GROUPS 不 仅仅 在 RAC 环境 下 有 用 ， 在 一 些 极端 条 件 下 ， 这 个 参数 在 单 实例 环境 中 也 能 发 挥 作 
Ho 在 一 个 插入 并 发 量 很 大 的 环境 中 C 比如 几 十 个 甚至 上 百 个 并 发 会 话 会 对 同一 张 表 进行 插入 ), 
我 们 可 能 经 常会 观察 到 这 张 表 的 段 头 的 等 待 ， 在 这 种 情况 下 ， 设 置 FREELIST GROUPS 大 于 1 
可 以 减少 由 于 FREELIST 争 用 而 导致 的 段 头 的 热 块 争 用 ， 多 个 FREELIST GROUPS 可 以 将 针对 
FREELISTS 的 并 发 操作 分 散在 多 个 FREELISTS BLOCK 中 ， 从 而 提高 并 发 插入 的 性 能 。 

本 节 介 绍 了 FREELISTS fil FREELIST GROUPS 参数 在 解决 大 并 发 量 插入 性 能 问题 时 的 很 多 
优点 ， 但 这 并 不 代表 我 们 可 以 滥用 它们 。 这 两 个 参数 也 有 一 些 缺 点 ， 多 个 FREELISTS 可 能 导致 
数据 块 中 的 数据 填充 率 变 低 ， 段 的 高 水 位 推进 过 快 , 存储 相同 数量 的 记录 ， 可 能 会 占用 更 多 的 数 
据 块 。 对 于 表 扫 摘 较 多 的 应 用 来 说 ,我 们 需要 慎重 考虑 二 者 的 正面 和 负面 影响 ， 从 而 权衡 使 用 这 
组 参数 。 一 般 来 说 , E OLTP 系统 中 ,插入 并 发 量 很 大 的 表 中 的 数据 量 也 很 大 ， 应 用 在 访问 这 些 
表 的 数据 时 , 通常 采用 索引 扫描 ， 因 此 加 大 这 组 参数 的 副作用 较 小 。 而 对 于 OLAP 系统 ， 切 不 可 
为 了 提高 数据 并 发 加 载 的 性 能 而 轻易 加 大 这 组 参数 , 因为 OLAP 系统 的 数据 经 常 需要 进行 全 表 扫 
描 ， 使 用 这 组 参数 可 能 会 影响 全 表 扫 描 的 性 能 。 

谈 了 这 么 多 ， 可 能 有 些 读者 会 说 ， 现 在 主流 的 数据 库 都 已 经 是 Oracle 10g 甚至 11g 版 本 了 ， 
从 Oracle 9i 开始 就 支持 ASSM 了 ,讨论 MSSM 是 不 是 已 经 没有 多 大 意义 了 呢 ? 事实 上 ,对 于 DBA 
来 说 ， 了 解 一 些 MSSM 的 技术 还 是 有 意义 的 ， 因 为 在 日 常 工作 中 ， 我 们 很 可 能 会 磁 到 Si 版 本 的 
数据 库 ， 也 可 能 磁 到 一 些 9; 或 者 10g 版 本 的 数据 库 ， 它 们 是 从 8i 版 本 升级 上 来 的 ， 可 能 很 多 表 
空间 都 是 MSSM 管理 模式 的 。 另 外 ， 为 了 规避 某 些 Bug ( 比如 ，9i 版 本 的 ASSM 表 空 间 由 于 对 
象 重 用 导致 的 ORA-600 [kcbget_xxx], ORA-600 [kcbnew_xxx] 这 类 Bug ), 可 能 也 需要 使 用 MSSM 
的 表 空 间 。 在 某 些 极 端的 情况 下 ， 为 了 避 开 ASSM 中 BITMAP 带 来 的 性 能 问题 ， 我 们 也 会 使 用 
MSSM (在 绝 大 多 数 情况 下 ，ASSM 的 BITMAP 机 制 在 性 能 上 优 于 FREELISTS 管理 模式 ， 不 过 
在 某 些 特 殊 应 用 情况 下 ， 则 恰恰 相反 )。 

通过 上 面 的 讨论 ， 大 家 是 否 已 经 掌握 了 MSSM 下 段 参数 的 设置 要 点 ? 实际 上 ， 在 具体 的 应 
用 环境 中 , 可 能 出 现 的 情况 远 比 老 白 和 大 家 一 起 探讨 的 要 复杂 得 多 , 如 何在 纷繁 复杂 的 环境 中 处 
理 好 这 几 个 看 似 很 简单 ， 但 是 又 很 让 人 头痛 的 参数 呢 ? 这 需要 数据 字典 的 设计 者 对 MSSM 的 管 
理 机 制 十 分 了 解 ， 另外 还 要 足够 了 解 自己 应 用 的 特点 , 这样 才 能 做 出 合理 的 选择 。 最 后 要 提醒 大 
家 的 是 ， 当 你 无 法 做 出 合理 的 判断 时 ,做 个 试验 可 能 是 比较 明智 的 选择 ， 到 底 哪 种 方案 更 好 ， 应 
用 系统 说 了 算 。 


10.1.3 减少 热 块 冲 突 的 方法 


实际 上 , 本 市 要 讨论 的 内 容 在 之 前 的 音节 中 已 陆续 提 及 过 , 这 里 只 是 想 通 过 系统 的 论述 加 深 
大 家 的 印象 。 热 块 冲突 是 最 为 常见 的 现象 ， 也 是 DBA 讨论 最 多 却 实践 最 少 的 部 分 。 几 乎 所 有 的 
系统 都 存在 热 块 冲突 的 问题 , 只 是 严重 程度 不 同 而 已 , 一 般 系统 的 热 块 冲突 对 系统 造成 的 影响 都 
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小 于 5%, 因此 绝 大 多 数 DBA 对 此 采取 了 容忍 的 态度 。 其 实 大 多 数 的 热 块 冲突 都 可 以 通过 应 用 方 
面 的 优化 来 解决 。 除 了 修改 SQL 外 ， 解 决 热 块 冲突 最 为 有 效 的 方法 就 是 调整 表 的 存储 结构 。 
为 了 探讨 这 一 话题 , 我 们 首先 需要 了 解 什么 是 热 块 冲突 ， 热 块 冲突 包含 哪些 形式 。 首 先 要 声 
明 的 是 ， 本 节 的 讨论 是 围绕 着 表 这 个 话题 的 , 解决 热 块 冲突 的 方法 有 很 多 , 我 们 会 在 今后 的 很 多 
话题 中 陆续 介绍 这 些 方法 ， 这 里 主要 讨论 如 何 通过 优化 表 的 结构 来 减少 热 块 冲突 。 
谈 到 热 块 冲突 ， 我 们 首先 需要 了 解 热 块 冲突 产生 的 原因 ， 从 Oracle 对 buffer busy waits 这 个 
等 待 事件 的 定义 上 可 以 看 出 一 些 端倪 ， 如 图 10-5 所 示 。 


BufferBusy Waits ID's and Meanings 
Reason Code (Id) 


F806 84A692F=104 U 
б 


р па [А block is being read 
003 100 п/а е want to NEW the block but the block is currently being read by another session (most likely for undo) 
007 200 п/а е want to NEW the block but ѕотеопе else has is using the current сору so we have їо wait for them to finish 
010 230 na [Trying to get a buffer in CR/CRX mode , but a modification has started on the buffer that has not yet been completed. 
012 F п/а ІА modification is happening опа SCUR or XCUR buffer, but has not yet completed 


012 (dup.) 231 n/a ICR/CRX scan found the CURRENT block, but a modification has started on the buffer that has not yet been completed 

Block is being read by another session and no other suitable block image was found e.g. CR version, so we wait until the read is 
completed. This may also occur after a buffer cache assumed deadlock. The kernel can't get a buffer in a certain amount of time 
013 130 п/а апа assumes а deadlock. Therefore it will read the CR version of the block. This should not have a negative impact оп 
performance, and basically replaces a read from disk with a wait for another process to read it from disk, as the block needs to be 
read one way or another 

e want the CURRENT block either shared or exclusive but the Block is being read into cache by another session, so we have to 


014 110 Ma ait until their read() is completed 
014 420 ha e want to get the block in current mode but someone else is currently reading it into the cache. Wait for them to complete the 
{duplicate} read. This occurs during buffer lookup. 
Тһе session wants the block in SCUR or XCUR mode. If this is a buffer exchange or the session is in discrete TX mode, the 
016 210 п/а session waits for the first time and the second time escalates the block as a deadlock and so does пої show up as waiting very 
ong. In this case the statistic: "exchange deadlocks" is incremented and we yield the CPU for the "buffer deadlock" wait event. 
016 020 ha During buffer lookup for a CURRENT copy of a buffer we have found the buffer but someone holds it in an incompatible mode so we 
(duplicate) have to wait. 
10-5 


buffer busy waits 等 待 事件 的 三 个 参数 中 的 前 两 个 是 文件 号 和 数据 块 号 ， 第 三 个 参数 在 8.0 ~ 
9.2 版 本 中 都 是 等 待 原因 ， 从 10.1 版 本 开始 ， 第 三 个 参数 的 含义 变 成 了 块 的 类 别 (BLOCK 
CLASS# )。 一 般 来 说 ，buffer busy waits 等 竺 事件 产生 的 主要 原因 有 以 下 几 个 方面 。 

о 访问 某 个 数据 块 时 ， 其 他 会 话 正 在 将 该 数据 块 读 和 DB Cache， 如 果 VO 系统 存在 性 能 问 

题 ， 那 么 会 加 重 这 种 类 型 的 等 待 。10g 版 本 中 将 这 种 buffer busy waits 独立 为 另外 一 个 等 
待 事件 read by another session ， 这 个 名 称 更 为 直观 。 

о 访问 某 个 数据 块 时 ， 这 个 数据 块 被 其 他 会 话 以 不 兼容 的 模式 所 持 有 。 

产生 等 待 的 BUFFER 可 能 是 段 头 ， 也 可 能 是 数据 块 、UNDO 数据 块 等 。 段 头 可 能 由 于 大 量 
的 并 发 插入 导致 FREELISTS 的 等 待 或 者 ASSM 下 段 头 里 的 位 图 块 (bmb block ) 等 待 。 对 待 不 同 
类 型 的 buffer busy waits 等 待 事件 ， 我 们 的 处 理 方法 也 是 不 同 的 。 

一 般 来 说 ， 段 头 的 等 待 主要 集中 在 FREELISTS 或 者 ВМВ 上 ， 可 以 通过 调整 FREELISTS 、 
FREELIST GROUPS 等 参数 来 解决 。 如 果 等 待 集中 在 BMB 上 ， 那 么 通常 只 能 通过 使 用 分 区 表 或 
者 调整 应 用 等 手段 来 解决 了 。 本 节 我 们 重点 讨论 如 何 减 少 表 数 据 块 上 的 热 块 冲突 。 

说 起 解决 数据 库 热 块 冲突 的 办 法 ,实际 上 有 两 条 路 :第 一 条 路 是 从 应 用 的 角度 减少 热 块 冲突 ， 
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第 二 条 路 是 减少 热 块 对 系统 的 影响 。 在 任何 一 个 系统 中 ,， 热 块 冲 突 都 是 避免 不 了 的 ,因此 在 日 常 
优化 时 , 我 们 首先 应 该 考虑 是 否 有 可 能 减少 热 块 冲突 带 来 的 影响 。 顺 着 这 个 思路 ， 就 可 以 找到 一 
些 这 方面 的 实施 手段 ， 比 如 提高 DB Cache 的 命中 率 (一 般 通 过 加 大 DB Cache 的 大 小 来 实现 )、 
使 用 多 缓冲 区 技术 等 。 在 我 经 历 过 的 案例 中 , 至少 有 30% 是 通过 上 述 手段 解决 问题 的 。 采用 这 些 
手段 解决 问题 代价 比较 小 ， 不 需要 花 大 力气 去 分 析 应 用 。 

前 面 我 们 也 讨论 过 ， 增 加 INITRANS 参数 可 以 有 效 避 免 由 于 事务 槽 等 待 而 产生 的 热 块 冲突 。 
加 大 PCTFREE 参数 的 值 ， 可 以 使 每 个 数据 块 存储 的 记录 数 减少 ， 从 而 减轻 热 块 冲突 。 比 加 大 
PCTFREE 参数 值 更 为 彻底 的 方法 ， 是 将 表 存 储 在 BLOCK_SIZE 更 小 的 表 空 间 上 。 

如 果 数 据 块 本 身 存在 热点 该 怎么 处 理 呢 ?这 个 问题 回答 起 来 有 点 麻烦 , 因为 既然 是 数据 ,就 
必然 存在 多 样 性 ， 所 以 不 存在 能 够 解决 问题 的 “灵丹妙药 ”。 除 了 刚才 提 到 的 方法 可 以 缓解 热 块 
冲突 外 ，Oracle 还 提供 了 一 系列 的 方案 ， 最 为 典型 的 是 HASH 分 区 表 和 HASH fx e 

HASH 分 区 表 是 解决 热 块 冲突 的 一 种 较为 常用 的 办 法 ,对 于 表 数 据 量 较 大 的 情况 , 可 以 考虑 
采用 HASH 分 区 表 。 比 如 , 一 张 表 的 主键 是 通过 SEQUENCE 产生 的 , 那么 在 没有 使 用 HASH 分 
区 表 的 情况 下 , 同一 个 时 间 点 产生 的 记录 存储 在 同一 个 数据 块 中 的 可 能 性 很 大 。 而 这 些 数据 随后 
又 被 其 他 应 用 使 用 ， 这 样 产生 热 块 的 可 能 性 就 很 大 了 。 但 如 果 将 这 张 表 根据 主键 设计 成 HASH 
分 区 表 , 那么 同一 个 时 刻 产 生 的 记录 就 被 散 列 算法 分 布 到 不 同 的 表 分 区 中 去 了 , 访问 这 些 数据 的 
时 候 就 可 以 从 多 个 数据 块 中 读 取 ， 从 而 缓解 了 热 块 冲突 。 

既然 HASH 分 区 表 这 么 强 ， 肯 定 有 些 朋 友 会 夸 春 欲 动 ， 干 脆 把 存在 热 块 争 用 的 表 都 设计 成 
HASH 分 区 表 好 了 。 实 际 上 ,任何 技术 都 有 其 两 面 性 ，HASH 分 区 表 解 决 了 热 块 冲突 的 问题 , 但 
是 又 带 来 了 另外 一 个 问题 。 如果 应 用 总 是 通过 主键 来 访问 这 张 表 的 数据 , 那么 这 种 方式 确实 是 最 
好 的 。 但 是 如 果 还 有 大 量 的 应 用 需要 根据 主键 进行 范围 扫描 , 或 者 按照 记录 的 生成 日 期 进行 范围 
扫描 ， 那 么 HASH 分 区 表 的 弱点 就 显现 出 来 了 。 原 本 放 在 同一 个 数据 块 中 的 数据 被 散 列 算法 分 
散 开 了 , 这 同时 意味 着 我 们 对 这 些 数据 做 范围 扫描 的 时 候 需 要 扫描 更 多 的 数据 块 。 这 就 是 HASH 
分 区 表 的 弱点 ， 它 增加 了 范围 扫描 的 成 本 。 

在 实际 的 生产 环境 中 , 我 们 可 能 不 总 是 那么 幸运 ,肯定 会 磁 到 两 方面 的 需求 : 一 方面 必须 解 
决 热 块 冲突 ,另外 一 方面 可 能 还 存在 一 些 应 用 要 对 这 些 数据 做 范围 扫 撒 。 在 这 种 情况 下 ， 必 须 进 
行 综合 的 评估 ， 确 定 到 底 哪 种 需求 才 是 主要 需求 。 如 果 优 化 范围 扫描 对 系统 更 有 利 , 那么 就 必须 
放弃 HASH 分 区 ; 而 如 果 解 决 热 块 冲突 更 为 重要 ， 那 么 就 必须 牺牲 范围 扫描 。 实 际 上 ，Oracle 
就 是 这 样 的 。 任 何 技术 都 是 矛盾 的 ， 有 缺陷 的 ， 和 否则 我 们 只 需要 记 住 一 些 准 则 ， 就 可 以 成 为 大 师 
To 成 长 为 Oracle 大师 并 非 易 事 ， 因 为 在 绝 大 多 数 情况 下 ， 没 有 一 成 不 变 的 准则 。 

HASH FEK (HASH cluster table) 不 是 分 区 表 ， 但 是 它 和 普通 表 ( 也 就 是 术语 所 说 的 堆 表 ， 
heap table ) 的 存储 方式 是 不 同 的 。 尽 管 HASH 簇 表 是 簇 表 的 一 种 ， 但 其 组 织 方式 是 根据 散 列 值 
来 进行 的 , 不 同 的 数据 块 中 存储 不 同 散 列 值 的 行 。 这样 一 来 ， 即 使 是 同时 插入 的 两 条 记录 ,也 有 
可 能 因为 某 个 字段 的 散 列 值 不 同 而 存储 在 不 同 的 数据 块 中 ， 从 而 最 大 限度 地 减少 热 块 冲突 。 

HASH 簇 表 主 要 适用 于 以 等 于 条 件 对 表 进 行 访问 , 且 很 少 根据 CLUSTER 键 值 进行 范围 扫描 
的 情况 。HASH 簇 表 除了 能 够 优化 热 块 冲突 外 ， 对 于 改善 大 表 的 SELECT 操作 也 有 一 定 的 作用 。 
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使 用 下 面 的 语句 可 以 创建 一 个 HASH £: 
SQL» CREATE CLUSTER off clu 


2 ( country VARCHAR2( 2), 
3 postcode VARCHAR2(10) ) 
4 SI ZE 350 
5 TABLESPACE case large data 
6 HASHKEYS 6000; 
SQL» CREATE TABLE office 
2 ( office cd NUMBER( 3), 
3 cost ctr NUMBER( 3), 
4 Country VARCHAR2(2), 
5 postcode VARCHAR2(10) ) 


6 CLUSTER off clu(country, postcode); 

创建 HASH 簇 表 时 的 主要 参数 包括 : 

О НАЅНКЕҮЅ, КЕҮ 的 数量 。 

口 HASH 15, 使 用 客户 自 定 义 的 散 列 函数 。 

口 SIZE， 预 留 的 空间 ， 用 以 存储 相同 散 列 值 的 不 同 HASHKEY 值 。 如 果 HASHKEY 的 长 度 
比较 大 ， 建 议 设置 较 大 的 值 。 

除了 HASH 分 区 表 和 HASH 徐 表 外 ,仍然 有 很 多 种 方法 可 以 用 来 减少 热 块 冲突 。 加 大 
PCTFREE 值 就 是 一 种 常用 上 且 简单 的 方法 。PCTFREE 参数 值 增加 后 , 平均 每 个 数据 块 中 的 记录 数 
就 会 减少 ， 从 而 减少 产生 热 块 冲突 的 机 会 。 

还 有 一 种 办 法 是 使 用 较 小 的 块 。 从 9i 版 本 开始 ，Oracle 提供 了 一 种 新 技术 , 用户 表 空 间 可 以 
设置 独立 的 块 大 小 , 而 不 需要 和 数据 库 的 默认 值 相同 , 这 种 技术 为 解决 热 块 冲突 提供 了 另外 一 种 
选择 。 不 过 在 实际 应 用 环境 中 , 我 们 很 少 能 见 到 使 用 了 这 一 技术 的 系统 ,这 是 因为 开发 厂商 往往 
不 了 解 这 种 技术 ， 因 此 也 很 少 设 计 这 样 的 系统 。 

至 此 ， 关 于 表 及 相关 存储 参数 的 讨论 就 告 一 段落 了 ， 但 在 后 续 章 节 中 我 们 还 会 继续 讨论 这 
个 永恒 的 话题 。 从 下 一 节 开 始 ， 老 白 将 通过 一 个 实际 的 优化 案例 来 重申 表 结 构 及 参数 设置 的 重 
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谈 到 容 灾 平台 ,很 多 DBA 总 是 觉得 这 离 自 己 很 远 ， 也 许 自己 一 辈子 也 看 不 到 容 灾 系统 的 局 
用 。 有 一 次 在 四 川 碰 到 几 个 朋友 , 谈 起 了 容 灾 平台 , 我 说 真正 能 启用 的 恐怕 不 到 一 半 ， 而 其 中 一 
位 以 前 在 某 省 邮 储 从 事 容 灾 工 作 的 朋友 则 表示 难以 置信 , 他 觉得 当年 自己 开发 容 灾 系统 时 是 很 认 
真 的 , 而 且 有 专人 管理 ,定期 演练 时 必须 确保 能 够 立马 切换 。 也 许 我 碰 到 的 客户 都 不 是 金融 行业 
的 ， 容 灾 建 设 比较 马虎 吧 。 

正巧 此 时 一 个 金融 行业 的 客户 打 来 求助 电话 ， 他 们 接 到 上 级 部 门 的 通知 ， 要 进行 容 灾 演练 ， 
而 在 切换 容 灾 系统 时 ， 却 发 现 系 统 中 一 套 10g 版 本 的 Oracle 数据 库 无 法 启动 。 

后 来 问题 解决 了 ,其实 很 简单 ， 他 们 的 容 灾 环境 采用 的 是 IBM 的 SVC 复制, 但 是 只 复制 了 
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数据 库 相 关 的 文件 ， 并 未 同步 操作 系统 的 系统 目录 中 的 文件 ， 而 且 host 文 件 的 配置 也 是 错误 的 ， 
所 以 才 导 致 数据 库 无 法 启动 。 这 个 问题 虽然 不 大 , 却 暴露 出 另 一 个 问题 , MERKER MATEM, 
当主 生产 环境 变更 时 , 没 能 及 时 变更 容 灾 环境 。 在 这 些 年 的 工作 中 ， 老 白 亲 自 经 历 过 三 次 容 灾 切 
Je, 其 中 两 次 成 功 , 一 次 失败 。 成 功 的 两 次 都 是 切换 到 本 地 容 灾 系 统 ， 而 失败 的 那 一 次 则 是 切换 
到 远程 容 灾 系统 。 

先 说 说 成 功 的 那 两 次 吧 。 当 时 客户 要 为 系统 添加 RAC 第 三 节点 ， 由 于 存储 容量 不 足 ， 无 法 
满足 第 三 节点 UNDO 表 空 间 和 归档 目录 的 需求 ， 因 此 决定 扩充 一 个 由 16 块 硬盘 组 成 的 扩展 柜 。 
由 于 集成 商 经 验 不 足 , 新 扩展 的 盘 柜 和 磁盘 的 微 码 与 原 系 统 不 兼容 ,扩容 工作 很 不 顺利 。 原 定 于 
周 五 晚上 添加 RAC 节点 ， 周 四 必须 完成 磁盘 扩容 工作 ， 但 是 从 周三 就 开始 的 盘 阵 扩容 进行 了 一 
天 半 还 是 毫 无 进展 。 于 是 IBM 的 售后 服务 人 员 也 加 入 了 此 项 工作 ， 经 过 诊断 ， 他 们 建议 现场 搬 
拔 一 下 磁盘 。 在 反复 了 几 次 后 ， 磁 盘 突 然 整个 锁 死 ， 系 统 无 法 正常 工作 了 ， 而 这 时 正好 是 下 午 5 
点 多 ， 系 统 业 务 最 高 峰 的 时 段 。 

经 过 我 和 客户 技术 主管 的 讨论 ,我们 决定 马上 切换 到 容 灾 系统 。 当 时 此 系统 有 两 套 容 灾 系 统 ， 
本 地 容 灾 采 用 DATAGUARD 技术 ， 远 程 容 灾 采 用 类 DATAGUARD 技术 将 归档 日 志 压 缩 后 传输 
到 远程 进行 注册 和 应 用 。 远程 容 灾 系 统 在 离 故障 点 100 多 公里 以 外 的 城市 , 配备 了 两 台 IBM P561 
服务 器 ， 而 本 地 容 灾 系 统 只 是 利用 剩余 设备 搭建 的 一 个 备份 平台 , 其 目的 并 不 是 为 了 容 灾 ， 而 是 
为 了 减轻 备份 对 生产 系统 的 负载 。 它 只 包含 一 台 IBM P561 服务 器 ， 且 仅 配 备 了 48 GB 的 内 存 ， 
此 配置 与 生产 环境 两 台 配 备 了 72 GB 内 存 的 P570 系统 相 比 ， 处 理 能 力 明 显 不 足 。 按 照常 理 ， 在 
这 样 的 情况 下 , 切换 到 异地 容 灾 系统 是 比较 合理 的 , 但 是 经 过 仔细 分 析 ， 当 时 并 不 具备 这 样 的 条 
件 , 因为 只 有 主 生产 系统 在 异地 建立 了 容 灾 系统 ,而 其 余 十 多 个 外 围 系 统 并 未 建立 相应 的 异地 容 
KA. 一 旦 将 主 生产 系统 切换 ,那么 就 需要 更 改 上 千 个 配置 项 才能 够 完成 全 业务 的 切换 ， 而 这 
项 工作 并 无 现成 的 预案 和 操作 脚本 , 仅 赁 人工 操作 ,很 难保 证 系统 正常 切换 。 男 外 还 有 一 个 更 大 
的 问题 ， 在 远程 容 灾 机 房 中 ， 仅 配备 了 几 个 初级 的 系统 管理 人 员 ， 并 未 配备 专职 DBA 等 维护 人 
员 , 一 旦 进行 切换 ， 大 家 只 能 在 远程 操作 系统 ， 很 难 确 保 切 换 过 程 不 出 问题 。 

如 果 切 换 到 本 地 容 灾 系统 ,只 需要 将 DATAGUARD 服务 器 的 人 * 改 为 生产 环境 的 了 全, 然后 激 
活 DATAGUARD 即 可 完成 ， 而 且 维 护 人 员 还 可 以 在 本 地 进行 操作 。 不 过 最 大 的 问题 是 本 地 的 硬 
件 配置 明显 不 足以 支撑 生产 环境 50% 的 业务 。 于 是 我 建议 将 生产 环境 上 的 部 分 内 存 插 到 容 灾 系 统 
的 服务 器 上 。 这 个 主意 似乎 很 不 错 ， 但 是 由 于 生产 环境 采用 的 是 P570 服务 器 ， 而 本 地 容 灾 系统 
采用 的 是 P561 服务 器 ， 大 部 分 从 P570 上 拔 下 的 内 存 条 并 不 能 在 P561 上 使 用 。 于 是 只 能 又 在 备 
FERETE, TEET 42 GB AF, 将 容 灾 服务 器 的 内 存 扩充 到 了 90 GB。 在 随后 重启 容 灾 服 
务 器 的 过 程 中 ,又 磁 到 了 网 卡 不 能 自动 激活 的 问题 ， 总 之 经 过 一 系列 的 处 理 , 终于 在 一 个 半 小 时 
后 恢复 了 系统 的 运行 。 虽 然 本 次 切换 最 终 成 功 了 ， 不 过 由 于 业务 高 峰 期 系统 停止 了 近 100 分 钟 ， 
大 量 业 务 被 积压 ， 并 影响 了 货物 通关 ， 最 终 导 致 了 惊人 的 损失 。 

在 这 次 事故 中 ， 投 入 大 量 资金 的 异地 容 灾 系 统 并 未 发 挥 应 有 的 作用 ， 反 而 是 不 在 规划 中 的 
DBA 的 无 心 之 作 解 救 了 这 次 危机 。 这 个 案例 也 暴露 出 了 此 容 灾 平 台 建设 中 的 问题 ， 这 些 问 题 其 
实 是 普遍 存在 的 。 
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第 二 个 案例 差不多 是 10 年 前 的 事情 了 ， 这 个 客户 采用 的 容 灾 技 术 和 第 一 个 案例 不 同 ， 是 采 
用 存储 级 复制 技术 , 容 灾 平 台 配 备 了 70% 的 处 理 能 力 。 那 次 老 白 正好 在 客户 现场 进行 男 外 一 套 系 
统 的 优化 。 由 于 生产 系统 的 存储 突然 掉 电 ,大 量 的 数据 文件 损坏 了 。 当 时 客户 还 很 淡定 ， 因 为 他 
们 投入 巨 资 建设 了 先进 的 容 灾 系 统 ,而 且 这 套 容 灾 系 统 在 几 个 月 前 还 做 过 切换 演练 。 但 是 容 灾 系 
统 启动 时 ， 其 中 的 一 台数 据 库 服 务 器 启动 不 了 ， 从 错误 信息 来 看 ， 是 由 ORA-704 和 ORA-600 fii 
误 引 起 的 。 当 值 DBA 忙碌 了 几 个 小 时 还 是 没 办 法 解决 问题 ， 突 然 想 到 这 边 还 有 一 个 做 优化 的 
DBA， 于 是 就 请 我 帮 他 解决 。 现 在 看 来 ， 那 个 问题 其 实 并 不 难 ， 主 要 是 由 于 UNDO 表 空 间 存 在 
坏 块 才 导 致 数据 库 无 法 正常 启动 , 通过 _offline_rollback_segments 和 _allow_resetlogs_corruption & 
Zt, ВНЛ ВВЕР, 强制 打开 数据 库 就 有 可 能 解决 问题 。 不 过 那 时 老 白 的 技术 还 比较 差 ， 整 整 折 
腾 了 一 天 也 没 能 解决 。 由 于 客户 建设 了 容 灾 系 统 ， 就 没有 再 建设 备份 系统 ,因此 这 个 系统 没有 可 
用 的 备份 集 ， 最 终老 白 只 能 佘 出 dul 这 个 法 宝 ， 导 出 了 数据 并 重建 了 整个 数据 库 。 虽 然 最 终 大 多 
数 数据 被 恢复 了 ， 不 过 整个 业务 却 中 断 了 5 天 之 久 。 

和 10 年 前 不 同 ， 现 在 的 容 灾 系统 建设 已 经 成 为 一 种 主流 ， 一 般 来 说 ， 核 心 的 业务 系统 都 会 
建设 容 灾 平台 。 不 过 和 10 年 前 类 似 的 是 ,现在 的 开 部 门 决策 者 还 是 不 了 解 容 灾 技术 的 本 质 ， 
此 在 选择 容 灾 平台 的 策略 上 , 仍 存在 很 多 误区 。 如 果 不 能 真正 从 原理 上 理解 容 灾 技 术 的 本 质 , JE 
么 就 无 法 保证 容 灾 切换 失败 的 严 剧 不 再 重演 。 
目前 的 主流 容 灾 技术 包括 下 面 几 种 : 

а 存储 同步 复制 技术 ; 

O 存储 异步 复制 技术 〈 包 括 各 种 类 型 的 存储 复制 以 及 卷 复 制 ); 
0 Oracle DATAGUARD; 

а 逻辑 复制 技术 ( 比如 STREAMS, GOLDENGATE, DSG 等 ); 
口 应 用 级 数据 复制 技术 。 

存储 同步 复制 技术 也 就 是 平常 所 说 的 镜像 (mirror ) 技术 ， 一 个 写 VO 必须 在 本 地 和 容 灾 系 
统 上 同时 完成 写 操作 才 算 操作 完成 ， 任 何 一 个 写 错 误 都 将 导致 整个 写 VO 失败 。 这 是 一 种 十 分 严 
格 的 同步 机 制 ， 因 此 能 够 确保 容 灾 平台 的 数据 随时 都 是 可 用 的 。 这 项 技术 是 十 分 成 熟 的 ， 其 至 
Oracle 都 专门 提供 了 一 套 解决 方案 一 一 RAC on Extended Distance Clusters， 就 是 一 套 远程 的 RAC 
系统 ， 两 个 节点 不 共享 一 个 磁盘 阵列 ， 而 是 共享 两 个 互 为 镜像 的 磁盘 阵列 ， 每 个 读 写 操作 都 会 发 
送 到 两 个 磁盘 阵列 上 。 一 旦 某 个 地 方 出 现 故 障 ， 那么 另外 一 个 地 方 的 系统 还 可 以 独立 工作 。 这 是 
一 种 兼顾 RAC 高 可 用 和 异地 容 灾 的 解决 方案 。 虽 然 目前 在 国内 还 缺乏 成 功 案例 ， 但 是 其 技术 成 
熟 度 已 得 到 验证 。 不 过 采用 镜像 技术 的 系统 , 一旦 某 个 存储 出 现 故 障 ， 必须 尽快 隔离 ， 否 则 就 会 
影响 系统 的 运行 ， 因 为 一 个 VO 操作 必须 同时 成 功 才能 够 完成 。 

存储 异步 复制 技术 目前 在 容 灾 系 统 上 的 应 用 十 分 广泛 , 这 种 方式 既 提供 了 易于 维护 的 高 效 容 
灾 复 制 , 又 避免 了 备用 存储 故障 导致 生产 系统 无 法 正常 工作 的 问题 。 但 是 如 果 深 入 研究 这 种 容 灾 
技术 的 本 质 ， 我 们 还 是 会 发 现 其 中 潜在 的 风险 。 为 什么 会 磁 到 这 样 的 案例 呢 ? 这 个 问题 在 10 年 
前 曾 使 老 白 十 分 困惑 ,不 过 随 着 对 Oracle 内 部 结构 的 认识 , 特别 是 对 数据 块 结构 的 认识 , 老 白 终 
于 明白 了 ， 导 致 当年 那个 问题 的 最 根本 原因 就 是 “ 块 断裂 "， 其 产生 的 根源 在 于 Oracle 的 数据 块 
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和 操作 系统 的 数据 块 大 小 不 一 致 。 一 般 的 UNIX 系统 ， 其 磁盘 块 的 大 小 是 512B, ifii Oracle 的 数 
据 块 大 小 是 8 KB， 也 就 是 说 ， 一 个 Oracle 数据 块 包含 了 若干 个 磁盘 块 。 从 Oracle 数据 块 的 定义 
上 来 看 , 虽然 Oracle 的 数据 块 分 配 的 磁盘 空间 是 连续 的 , 但 由 于 底层 存储 条 带 技 术 , 系统 不 能 确 
f: Oracle 数据 块 在 磁盘 上 是 连续 分 布 的 ， 甚 至 一 个 Oracle 数据 块 有 可 能 被 存储 在 多 个 磁盘 中 。 
由 于 Oracle 数据 块 和 操作 系统 磁盘 块 之 间 的 不 同 ， 就 产生 了 一 种 可 能 性 : 一 个 Oracle 数据 块 被 
操作 系统 分 成 了 多 个 VO 写 盘 ， 这 些 IO 之 间 的 时 间 点 是 不 同 的 ， 因 此 在 某 个 瞬间 ， 远 程 容 灾 系 
统 上 数据 中 可 能 包含 了 一 个 数据 块 的 某 个 部 分 的 变更 , 但 是 缺少 了 其 他 部 分 的 变更 , 这 就 导致 该 
数据 块 中 的 各 个 组 成 部 分 是 不 一 致 的 。 通过 块头 和 块 尾 以 及 校 验 和 的 比较 , 就 能 发 现 数据 块 处 于 
不 一 致 状态 。 这 种 情况 的 表象 就 是 Oracle 读 到 了 坏 块 , 也 就 是 我 们 常 说 的 块 断裂 现象 。 这 就 是 为 
什么 使 用 存储 异步 复制 技术 的 容 灾 系统 , 在 数据 库 打开 后 经 常会 发 现 坏 块 的 原因 。 如 果 坏 块 正好 
出 现在 UNDO 表 空 间 中 ， 或 者 出 现在 一 些 关键 的 系统 数据 字典 表 中 ， 那 么 在 打开 这 个 数据 库 时 
就 可 能 会 出 现 问题 。 

对 于 一 般 的 系统 , 块 断裂 发 生 的 几率 并 不 是 太 高 , 但 是 对 于 数据 变更 十 分 频繁 的 7x24 系统 
来 说 ,出 现 的 几率 会 大 得 多 。 之 所 以 那个 客户 在 容 灾 演练 时 没有 发 现 问题 ,主要 是 因为 客户 在 此 
期 间 通 常会 停 掉 业 务 , 这 样 数据 库 就 处 于 相对 的 静态 ， 出 现 问 题 的 几率 很 小 , 而 实际 生产 系统 故 
障 需 要 切换 时 往往 是 业务 高 峰 ， 出 现 块 断裂 的 可 能 性 几乎 是 100%。 

这 类 容 灾 技术 有 很 多 ， 主 要 的 方案 提供 厂商 包括 EMC、 赛 门 铁 克 ( 赛 门 铁 克 采用 卷 复 制 技 
Ж), KR, HP. ІВМ 等 。 原 厂 的 工程 师 总 会 宣称 他 们 的 算法 是 经 过 严格 认证 的 ， 能 够 确保 容 灾 
系统 上 的 数据 完全 复制 自生 产 系 统 上 某 一 瞬间 的 数据 , 并 且 在 时 间 点 上 肯定 是 一 致 的 , 因此 不 存 
在 不 可 用 的 问题 。 这 个 说 法 看 似 很 有 道理 ,不 过 仔细 考虑 一 下 ， 好像 还 是 存在 漏洞 。 时 间 上 的 一 
致 性 ， 就 能 确保 数据 库 的 一 致 性 吗 ?” 要 解决 这 个 问题 ， 就 需要 认真 研究 数据 库 一 致 性 的 条 件 。 我 
们 假定 有 一 个 一 致 性 的 存储 快照 (snap )， 在 这 个 快照 上 上， 没有 任何 一 个 数据 块 是 断裂 的 ， 那 么 
我 们 认为 这 个 快照 是 一 致 性 的 ; 反之 这 个 快照 是 非 一 致 性 的 , 在 这 种 情况 下 打开 数据 库 ， 可 能 就 
会 出 现 坏 块 。 如 果 坏 块 出 现在 SYSTEM 表 空 间或 者 UNDO 表 空 间 中 , 数据 库 甚 至 可 能 无 法 打开 。 
即使 某 个 快照 是 一 致 的 ， 数 据 库 就 一 定 能 打开 吗 ? 在 进行 数据 库 介 质 恢复 时 ， 如 果 在 某 个 SCN 
停止 了 恢复 ， 系 统 提示 某 些 文件 还 处 于 不 一 致 状态 ， 此 时 打开 数据 库 会 出 现 故 障 ， 这 种 情况 下 ， 
即使 RECOVERPOINT 和 SCN 是 完全 一 致 的 ， 数 据 库 中 的 某 个 数据 文件 也 可 能 存在 问题 (可 以 
通过 V$DATAFILE_HEADER 的 FUZZY 字段 来 判断 是 否 有 文件 的 FUZZY 是 “Y”， 这 个 视图 的 
数据 是 从 文件 头 中 读 取 的 ), 这 时 打开 数据 库 , 某 些 数据 文件 可 能 就 会 出 现 坏 块 , 如 果 是 SYSTEM 
或 者 UNDO 表 空 间 的 文件 中 存在 坏 块 ， 那 么 数据 库 打 开 后 ， 有 可 能 还 是 会 因为 ORA-600 错误 而 
无 法 正常 工作 。 

从 这 一 点 ， 老 白 想 到 了 几 年 前 和 几 个 赛 门 铁 克 的 工程 师 讨 论 他 们 的 基于 卷 复制 的 容 灾 平台 。 
当时 的 生产 库 是 一 套 10g RAC 和 一 个 逻辑 STANDBY 实现 的 报表 系统 ， 需 求 是 当 容 灾 发 生 时 ， 
系统 可 以 顺利 切换 并 且 报 表 系 统 的 逻辑 STANDBY 还 能 继续 工作 ,也 就 是 说 容 灾 系统 上 的 生产 库 
和 报表 系统 之 间 的 逻辑 STANDBY 必须 能 够 继续 保持 关系 ,这 就 要 求 切 换 的 时 候 两 个 系统 还 要 保 
FF SCN 的 一 臻 性 。 起 初 ， 赛 门 铁 克 的 工程 师 也 认为 他 们 的 产品 是 无 懈 可 击 的 ， 后 来 经 过 测试 发 


= 
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现 , 切换 时 经 常会 有 坏 块 出 现 。 虽然 如 此 ,他们 总 是 能 够 从 中 找到 一 个 时 间 点 ， 在 这 个 时 间 点 上 
做 切换 总 是 可 以 完全 恢复 。 实 际 上 ， 这 个 案例 从 侧面 印证 了 老 日 的 观点 ， 由 于 SCN 在 时 间 上 的 
不 连续 性 ， 导致 一 部 分 时 间 点 的 数据 是 一 致 的 ， 而 男 一 部 分 时 间 点 的 数据 是 不 一 致 的 。 因 此 采用 
类 似 技 术 的 容 灾 系统 ， 不 论 其 技术 如 何 先 进 ， 都 存在 相同 的 隐患 。 

既然 存储 复制 容 灾 容易 出 现 块 断裂 , 那么 它 是 不 是 就 没有 用 武之 地 了 呢 ? 这 是 不 能 一 概 而 论 
的 。 随 着 存储 复制 容 灾 技术 的 不 断 改 进 , 现在 的 技术 又 有 了 新 的 发 展 。 为 了 提高 存储 容 灾 系统 启 
用 时 的 可 用 性 ， 可 以 在 每 天 业务 量 不 是 很 高 的 时 候 ， 对 主要 表 空间 设置 BEGIN BACKUP 状态 ， 
然后 做 一 个 快照 , 再 设置 为 END BACKUP, 一 旦 激活 容 灾 系统 时 出 现 了 ORA-704 或 者 ORA-600 
这 样 的 错误 ， 就 可 以 从 那个 时 间 点 通过 归档 日 志 RECOVER DATABASE 恢复 数据 ， 从 而 获得 一 
个 可 用 的 数据 库 。 

在 官方 文档 Supported Backup, Restore and Recovery Operations using Third Party Snapshot 
Technologies [ID 604683.1] 中 Oracle 提出 了 一 个 不 需要 BEGIN BACKUP/END BACKUP 也 能 实 
现 一 致 性 复制 的 设想 。 这 篇 文章 往往 令 很 多 存储 厂商 认为 ， 自 己 的 存储 产品 是 不 使 用 BEGIN 
BACKUP/END BACKUP 就 总 能 够 在 容 灾 系 统 正常 打开 数据 库 的 。 因 为 Oracle 的 官方 文档 中 有 这 
么 一 句 : Oracle will officially support the following operations assuming that the third party snapshot 
technology can meet the prerequisites listed in the next 2 sections. ( Oracle 支持 下 列 操作 ， 只 要 第 三 
方 快 照 技 术 符 合 下 面 两 节 里 列 出 的 前 提 条 件 。) 

不 过 如 果 你 继续 阅读 下 面 的 前 提 条 件 : 

第 三 方 快照 前 提 条 件 

第 三 方 厂商 需要 保证 其 快照 符合 如 下 要 求 : 

(1) 5j Oracle 推荐 的 上 述 恢复 操作 完好 集成 


(2) 数据 库 在 快照 点 上 一 致 性 宕 掉 ; 

(3) 快照 中 对 每 个 文件 的 写 顺序 加 以 保留 。 

就 会 发 现 这 种 场景 对 快照 的 要 求 十 分 苛刻 。 第 一 点 和 第 三 点 比较 容易 实现 ， 目 前 EMC 的 
SRDF. HDS 等 产品 都 支持 根据 写 顺 序 的 数据 复制 。 而 第 二 点 “数据 库 在 快照 点 上 一 致 性 宕 掉 ” 


是 十 分 苛刻 的 。 在 真正 的 容 灾 环 境 下 , 有 可 能 总 是 能 幸运 碰 到 这 种 情况 吗 ? 很 多 客户 在 测试 类 似 
的 容 灾 平台 的 时 候 , 总 是 通过 突然 杀 掉 生产 库 的 实例 来 验证 容 灾 是 否 起 效 , 这 么 测试 肯定 是 百 分 
百 的 成 功 ， 因 为 这 种 情况 对 于 容 灾 库 而 言 ， 就 像 是 数据 库 实例 宕 掉 后 重启 一 样 。 如 果 你 尝试 在 生 
产 库 直 接 关 掉 存储 (包括 备用 电池 )， 这 种 情况 下 ， 你 的 容 灾 库 是 否 还 能 很 幸运 地 启动 呢 ?” 我 想 
如 果 这 样 ， 你 真 的 十 分 幸运 。 

Oracle DATAGUARD 是 一 种 适合 本 地 容 灾 的 解决 方案 , 由 于 DATAGUARD 是 基于 Oracle Ж 
据 块 的 复制 技术 ， 它 不 会 造成 块 断裂 ， 因 此 很 适合 本 地 容 灾 系 统 使 用 。DATAGUARD 的 缺点 是 ， 
如 果 采 用 LGWR 同步 模式 , — Н DATAGUARD 出 现 故 障 , 将 导致 生产 库 也 无 法 使 用 ; mi Rc 
JH LGWR 异步 模式 或 者 ARCH 传输 模式 ,一旦 主 库 故障 ， 丢 失 的 数据 量 可 能 会 多 于 存储 复制 技 
术 的 丢失 量 。 

除了 上 述 几 种 常见 的 数据 库容 灾 技 术 外 , 近年 来 , 又 出 现 了 以 Oracle GOLDENGATE DSG. 
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Oracle Streams 为 代表 的 逻辑 复制 解决 方案 。 这 些 解决 方案 基本 上 都 是 通过 对 Oracle 日 志 进 行 挖 
所 ,将 逻辑 变化 记录 捕获 后 传输 到 目标 端 ， 转 换 为 SQL 语句， 并 应 用 到 目标 数据 库 ， 从 而 实现 
数据 同步 。 目 前 已 经 有 很 多 用 户 使 用 这 些 产品 建立 了 自己 的 容 灾 平台 。 这 种 容 灾 手段 避免 了 数 
据 块 断裂 的 问题 ,在 某 些 场合 下 是 适用 的 。 不 过 这 种 基于 逻辑 复制 的 技术 存在 一 个 很 大 的 缺点 ， 
就 是 无 法 有 效 控 制 数 据 复制 的 延 时 ， 对 源 端 的 系统 依赖 较 大 ， 而 且 对 大 批量 数据 维护 工作 有 较 
严格 的 限制 。 而 这 些 逻 辑 复制 产品 ， 对 于 大 事务 的 控制 都 存在 一 定 的 缺陷 ， 比 如 ， 生 产 环境 做 
了 一 个 UPDATE 操作 ， 修 改 了 2000 万 条 记录 ， 这 个 操作 在 生产 环境 中 可 能 10 分 钟 就 完成 了 ， 
而 在 目标 端 ， 该 操作 就 变 成 了 2000 万 个 独立 的 UPDATE 语句， 执行 完成 这 些 UPDATE 操作 , 
可 能 需要 几 个 小 时 ,其 至 更 长 的 时 间 ， 这 样 就 会 造成 复制 的 延迟 。 如 果 这 时 生产 系统 出 现 故 障 ， 
那么 恢复 业务 可 能 需要 较 长 的 时 间 ， 甚 至 有 可 能 出 现 一 些 更 为 严重 的 问题 。 比 如 对 于 
GOLDENGATE 来 说 ， 其 捕获 进程 在 某 个 事务 没有 提交 时 不 会 捕获 数据 ， 只 有 当 事 务 提 交 时 才 
会 捕获 ， 如 果 某 个 事务 执行 的 时 间 比 较 长 ， 那 么 捕获 进程 会 等 待 该 事务 提交 ， 这 样 就 会 产生 较 
大 的 延 时 ， 如 果 这 时 系统 出 现 故障 ， 就 会 出 现 大 量 没 有 来 得 及 捕获 的 数据 ， 这 些 数据 可 能 会 彻 
REK, 

针对 大 事务 ，GOLDENGATE 进行 了 一 定 的 优化 ， 比 如 对 于 INSERT 操作 , GOLDENGATE 
会 自动 合并 类 似 的 语句 ， 采 用 BULK INSERT 的 方式 处 理 ， 这 种 方式 已 经 被 证 明 是 十 分 有 效 的 ， 
对 于 批量 插入 操作 的 复制 效果 很 好 。 不 过 对 于 UPDATE 和 DELETE 操作 ， 上 述 处 理 方式 并 没有 
实现 。 系 统 是 复杂 多 变 的 ， 实 际 环境 并 不 总 是 以 我 们 个 人 的 意愿 而 改变 。 

只 有 了 解 了 主要 复制 技术 的 基本 实现 原理 ， 我 们 才能 在 设计 自己 的 容 灾 平 台 时 选用 正确 的 
方案 。 

逻辑 复制 技术 对 于 数据 量 不 大 ， 很 少 有 大 事务 的 系统 是 有 效 的 ， 但 如 果 将 其 用 于 容 灾 系 统 ， 
就 需要 加 强 对 系统 运行 状况 的 监控 。 通 过 心跳 表 监 控 可 以 及 时 发 现 延 迟 增 大 问题 。 在 一 个 逻辑 复 
制 环境 中 ,目标 系统 出 现 性 能 问题 , 或 者 目标 系统 中 某 个 不 合理 的 查询 ,都 有 可 能 让 复制 延 时 变 
得 很 大 ( 老 白 以 前 甚至 还 碰 到 过 由 于 没有 及 时 在 目标 环境 中 进行 表 分 析 而 导致 复制 进程 采用 了 错 
误 的 执行 计划 ， 从 而 使 得 复制 延 时 变 大 )。 另 外 ， 在 逻辑 复制 环境 中 ， 应 尽 可 能 保证 目标 服务 器 
的 性 能 ， 从 而 避免 复制 延 时 。 

DATAGUARD 适用 于 本 地 容 灾 ， 对 于 一 些 数 据 变化 比较 大 的 系统 ， 传 输 大 量 的 归档 日 志 需 
要 很 高 的 网 络 带宽 。 

存储 级 别 数据 复制 技术 由 于 传输 的 仅仅 是 存储 数据 的 变化 ， 其 传输 数据 量 小 于 
DATAGUARD, ， 因 此 很 适合 在 广域网 上 进行 数据 复制 。 这 种 复制 模式 很 适用 于 异地 容 灾 平台 。 

对 于 不 同 的 应 用 , 不同 的 SLA， 选 择 合适 的 容 灾 技 术 十 分 关键 。 在 本 地 建立 DATAGUARD 
本 地 容 灾 系统 ， 远 程 使 用 基于 存储 复制 技术 的 远程 容 灾 系统 ， 也 许 是 不 错 的 选择 。 


10.3 “案例 简单 任务 
本 节 内 容 摘自 老 白 的 日 记 。 
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11H24H 令 人 意外 的 开始 


今天 是 我 第 一 天 到 用 户 现场 ,在 香格里拉 酒店 和 老 方 会 合 。 老 方 在 原 厂 ， 出 差 必须 享受 五 星 
级 标准 ， 而 我 觉得 400 多 元 钱 的 酒店 有 点 奢侈 ,就 住 在 了 旁边 的 迎 宾 馆 。 迎 宾馆 是 原来 的 市 委 招 
待 所 ， 后 来 改造 成 了 一 个 三 星 级 酒店 ,房间 虽然 有 点 旧 , 但 是 十 分 干净 。 院 子 很 大 ， 里面 非 常安 
项。 最 关键 的 是 ,一 个 市 政府 的 朋友 给 我 打 了 个 很 不 错 的 折扣 ,不 到 200 元 的 价格 是 我 选择 这 里 
的 主要 原因 。 

客户 在 开发 区 ， 从 市 区 打车 过 去 要 40 多 分 钟 ， 在 车 上 老 方 给 我 介绍 了 这 个 项 目 。 老 方 是 这 
个 项 目的 负责 人 ,前 期 也 担任 了 售 前 的 工作 。 听 老 方 介绍 ， 这 是 一 个 短信 平台 的 优化 项 目 ， 用户 
的 优化 目标 是 将 系统 整体 的 处 理 能 力 提 升 25% 以 上 , 不 过 并 没有 对 CPU 资源 、IO 等 提出 明确 的 
BOR, EW, 这 个 优化 指标 好 像 并 不 高 ， 老 方 也 觉得 这 是 个 很 简单 的 任务 ， 只 要 花 点 心思 优化 
JL SQL, 应 该 不 难 达到 。 在 出 租车 上 的 这 段 时 间 , 我 们 俩 都 很 轻松 , 老 方 甚至 考虑 到 不 要 过 早 
结束 项 目的 问题 ,因为 客户 出 了 一 个 不 错 的 价格 ,如果 我 们 过 去 两 三 下 就 解决 了 问题 ,客户 或 许 
会 觉得 钱 花 得 有 点 冤枉 。 

上 午 是 项 目 启动 会 ， 甲 方 的 项 目 经 理 姓 余 ， 是 个 80 后 的 美女 ， 高 挑 的 身材 ， 说 话 甜 甜 的 。 
从 甲 方 对 项 目的 期 望 来 看 ， 确 实 像 老 方 所 说 ,不 算 太 高 ， 相 比 我 们 以 前 做 过 的 项 目 要 简单 一 些 。 
这 是 一 个 短信 平台 的 系统 ,在 平时 是 没有 任何 问题 的 , 只 有 在 中 秋 节 和 春节 期 间 会 出 现 性 能 问题 ， 
导致 短信 话 单 无 法 正常 入 库 , 严重 的 时 候 , 为 了 确保 短信 系统 能 够 正常 运作 , 会 出 现 应 用 软件 被 
迫 丢 弃 话 单 的 情况 。 对 于 运营 商 来 说 ,丢弃 话 单 就 意味 着 话费 的 流失 ,每 年 由 此 导致 的 话费 流失 
可 达 数 百 万 之 多 。 这 还 不 是 最 大 的 问题 ， 由 于 丢失 的 短信 话 单 有 可 能 是 某 个 SP 的 业务 短信 ， 这 
就 会 导致 SP 业务 收入 方面 的 损失 。 为 了 确保 业务 高 峰 期 不 丢失 短信 话 单 ， 甲 方 希望 本 次 优化 能 
够 将 目前 每 秒 最 大 入 库 短信 量 从 1200 条 左右 提高 到 1500 条 以 上 。 对 于 其 他 方面 的 优化 ,能 实现 
多 少 就 算 多 少 ， 只 要 事务 平均 响应 时 间 能 够 提升 20% 以 上 ， 项 目 就 可 以 验收 了 。 

今天 参加 开工 会 的 除了 甲 方 外 ， 还 有 开发 商 的 技术 人 员 ， 他 们 对 这 次 优化 的 态度 十 分 友好 ， 
也 希望 我 们 能 够 对 系统 的 性 能 提出 一 些 有 效 的 建议 , 以 便于 日 后 改进 。 另 外 他 们 还 表示 ， 只 要 我 
们 的 优化 建议 可 靠 ， 他 们 一 定 会 在 20 个 工作 日 内 完成 修改 工作 。 

这 个 会 只 开 了 个 把 小 时 ， 就 在 友好 的 气氛 中 结束 了 。 甲 方 的 小 余 帮 有 我 们 在 旁边 的 ADC H H 
组 办 公 室 里 找到 了 两 个 空 座位 ， 然 后 就 是 申请 网 禁 ， 申请 工作 账号 等 。 运 营 商 在 安全 方面 管理 得 
比较 严 , 我 们 填写 了 数 份 表格 , 复印 了 身份 证 ,其 至 在 安全 责任 书 上 按 了 指 印 , 终于 可 以 连 到 服 
务 器 了 。 看 看 时 间 已 经 是 中 午 11:50 了 ， 于 是 我 和 老 方 锁 了 电脑 屏幕 ， 到 外 面 去 找 吃 饭 的 地 方 。 
老 方 对 这 个 地 方 也 不 熟悉 ,我 们 俩 转 了 半天 , 终于 发 现 了 一 条 比较 热闹 的 街道 ,街道 两 边 有 
几 家 饭店 和 一 个 不 大 不 小 的 超市 。 老 方 是 山西 人 ， 比 较 喜 欢 面 食 ， 于 是 我 们 选 定 了 一 家 规模 比较 
大 的 饺子 馆 。 虽然 是 在 西南 , 但 是 这 家 饺子 馆 还 颇 有 北方 的 风味 ,两 个 人 吃 得 都 比较 满意 。 回 来 
的 路 上 ,我 顺便 在 超市 严 了 一 个 茶杯 。 我 这 个 人 喜欢 喝 茶 ， 不 过 出 差 总 是 忘记 带 杯子 ， 于 是 每 到 
一 个 地 方 ， 总 是 先 找 超 市 买 茶杯 。 还 好 我 喜欢 的 是 绿茶 ， 随 便 找 个 茶杯 就 可 以 泡 。 

回 到 办 公 室 的 时 候 , 已 经 快 两 点 了 。 客 户 下 午 两 点 上 班 , 办 公 室 里 不 少 人 还 躺 在 简易 床上 睡 
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午觉 。 我 先 把 杯子 洗 了 洗 ， 泡 上 一 杯 茶 ， 然 后 登录 到 系统 看 了 看 。 这 个 短信 平台 分 为 两 个 区 ， 分 
别 负责 半 个 城市 的 业务 。 这 两 个 区 根据 机 房 的 地 点 被 命名 为 A 系统 平台 和 B 系统 平台 ， 服 务 器 
Æ IBM 的 P 了 系列 ,操作 系统 是 AIX5.3。A 平 台 是 早期 建设 的 ,数据库 是 8.1.7.4 版 本 ; B 平台 是 
前 几 年 扩容 的 ， 数 据 库 版 本 是 9.2.0.6。 

我 首先 查看 了 两 套 系统 的 STATSPACK ， 都 是 新 装 的 ， 并 开 了 自动 采样 ， 估 计 这 还 是 老 方 上 
个 月 来 这 里 做 售 前 的 时 候 装 的 。 接 着 ， 我 在 A 平台 上 生成 了 一 份 今天 上 午 9:00 ~ 10:00 的 
STATSPACK 报告 ， 报 告 显 示 每 秒 逻 辑 读 和 物理 读 的 数量 都 很 小 ， 逻 辑 读 只 有 五 六 千 ， 平 均 每 秒 
的 事务 数 也 只 有 0.93。 想 起 刚才 小 余 说 过 ， 这 套 系 统 平时 的 负载 很 小 ，CPU 使 用 率 只 有 20% 左 
A, VO 也 很 闲 。 确 实 如 她 所 说 ， 现 在 是 下 午 两 点 多 ，CPU 的 使 用 率 只 有 10% 多 一 点 。 我 继续 往 
下 看 STATSPACK 报告 ， 并 没有 发 现 什么 开销 较 高 的 SQL， 排 名 第 一 位 的 SQL 是 一 条 INSERT 
语句 ， 它 向 一 张 SM_HISTABLE 表 搬 入 一 条 记录 ， 根 据 表 名 判断 ， 这 应 该 就 是 那 张 短信 话 单 表 。 
这 条 语句 在 一 个 小 时 内 执行 了 59 万 次 , 平均 算 下 来 每 秒 不 到 200 条 ， 每 次 执行 产生 的 逻辑 读数 
量 为 14.2。 在 浏览 了 一 遍 STATSPACK 报告 后 ， 除 了 部 分 SQL 没有 使 用 绑 定 变量 ， 硬 分 析 比 例 
略 高 之 外 ,我 并 没有 发 现 什么 明显 的 问题 。 因 为 没有 采集 到 业务 高 峰 的 数据 ， 所 以 没有 明显 的 问 
题 也 很 正常 ， 不 过 我 突然 意识 到 一 个 较为 严重 的 问题 。 在 我 浏览 TOP SQL 这 一 节 时 ， 看 到 的 单 
次 执行 开销 最 大 的 SQL 每 次 执行 产生 的 逻辑 读 操 作 只 有 不 到 2000 个。 这 说 明 系 统 中 并 没有 很 多 
高 开销 的 SQL， 这 样 一 来 ,早上 我 和 老 方 商定 的 优化 几 个 高 开销 SQL 的 计划 就 很 难 实施 了 。 

我 急忙 把 老 方 叫 到 门 外 ， 把 刚才 的 发 现 告诉 了 他 。 老 方 也 觉得 有 点 意外 ,由 于 这 次 客户 的 优 
化 目标 并 不 高 , 他 认为 达到 优化 目标 没有 任何 问题 ,因此 对 于 这 套 系统 ,他 并 没有 像 以 往 那 样 在 
售 前 阶段 进行 详细 的 分 析 。 

我 发 现 这 套 系 统 其 实 十 分 简单 ， 除 了 那 条 开销 最 大 的 插入 语句 ， 只 有 少量 的 SELECT 语句 ， 
而 且 大 多 数 SELECT 语句 都 是 根据 主键 MSG_ID 访问 的 ,只 有 少量 通过 PHONE NO 查询 。 对 这 
样 一 套 系 统 进行 优化 ， 想 从 SQL 入 手 , 佑 计 难 度 较 大 ， 我 们 必须 另辟蹊径 。 

如 果 不 从 SQL 入 手 ， 我 们 该 从 哪里 开始 呢 ? 这 么 简单 的 应 用 ， 想 要 通过 操作 系统 和 数据 库 
参数 方面 的 调整 提升 20% ~ 30% 的 性 能 ， 是 不 太 现 实 的 。 调 整 应 用 的 架构 可 能 是 最 佳 选择 ,不 过 
这 样 的 话 ， 对 应 用 调整 过 大 ， 开 发 商 估计 也 会 有 很 大 的 阻力 。 

讨论 了 半天 , 我 和 老 方 也 没 想 出 什么 好 的 办 法 , 于 是 我 建议 还 是 先 找 开发 人 员 了 解 一 下 应 用 
的 情况 再 说 。 从 目前 的 情况 看 ， 只 能 先 搞 明白 应 用 的 关键 瓶颈 ， 再 去 想 其 他 办 法 了 。 

经 过 了 解 , 我 大 体 明 白 了 这 个 系统 的 关键 问题 。 这 是 一 个 短信 平台 中 的 后 台 系 统 , 用 于 存储 和 
管理 短信 话 单 ， 来 自 短信 平台 的 话 单 首 先 会 存储 在 内 存 缓冲 中 ， 然 后 被 后 台 进程 批量 写 人 数据 库 。 
每 个 平台 都 配置 了 8 个 并 发 的 写 人 进程 , 用 于 短信 话 单 的 写 和 人 操作 , 每 次 写 入 的 批量 为 800 条 。 开 
发 人 员 也 曾 尝 试 过 增加 写 入 进程 和 增加 写 入 批量 的 数量 , 不 过 效果 都 不 明显 。SM_HISTABLE 是 一 
张 分 区 表 ， 首 先 他 们 设计 了 每 个 月 生成 一 张 话 单 表 ， 表 名 为 SM_HISTABLEyymm， 每 张 表 又 按照 
每 天 一 个 分 区 , 分 为 多 个 分 区 , 分 区 主键 是 CREATED. DATE, 每 条 话 单 都 有 唯一 的 主键 MSG ID, 
话 单 插入 后 , 后 续 处 理 主要 根据 MSGID 来 查询 话 单数 据 , 在 更 新 数据 时 ,一般 都 采用 ROWID Ж 
件 进行 ， 这 方面 也 不 会 有 性 能 问题 。 
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从 这 种 简单 的 应 用 系统 来 看 , 我 们 能 够 进行 优化 的 点 并 不 多 。 看 样子 我 们 需要 认真 地 考虑 一 
下 这 个 特殊 的 应 用 了 ， 想 想 如 何 来 完成 这 个 现在 看 来 并 不 简单 的 “简单 任务 ”。 


11 月 25 日 “解决 之 首 


今天 一 早 , 老 方 就 回 北京 了 。 昨天 晚上 我 和 老 方 一 直 在 讨论 这 个 项 目 , 从 采集 到 的 信息 来 看 ， 
只 能 通过 调整 操作 系统 数据库 的 参数 ,以 及 调整 表 的 一 些 参数 来 达到 提升 系统 总 体 性 能 的 目标 。 
而 对 于 系统 性 能 来 说 ， 最 为 关键 的 也 就 是 大 量 的 话 单 插入 操作 。 目 前 话 单 插 和 人 是 由 8 个 并 发 进程 
完成 的 ， 每 次 的 插入 批量 是 800 条 记录 。 

虽然 实际 情况 和 预先 估计 有 出 人 , 但 也 只 能 硬 着 头皮 上 了 。 今天 我 会 主要 分 析 在 哪些 环节 可 
以 进行 优化 ， 以 及 每 个 环节 可 能 的 性 能 提升 比例 ， 从 而 为 制定 优化 计划 提供 参考 。 另 外 ,采集 性 
能 基线 的 工作 也 在 同时 进行 , 由 于 这 个 项 目的 特殊 性 , 我们 无 法 采集 到 去 年 春节 期 间 的 数据 。 对 
这 种 系统 来 说 , 进行 非 业 务 高 峰 期 的 性 能 数据 比较 , 意义 并 不 是 很 大 。 通 过 昨天 的 分 析 可 以 看 出 ， 
平时 每 天 的 话 单 量 在 2000 万 条 左右 ， 而 在 中 秋 节 和 除夕 ， 话 单 量 可 能 达到 1.8 ~ 2 亿 。 按 照 繁忙 
时 集中 系数 为 0.1 计算 ， 平 时 每 天 最 忙 的 1 个 小 时 内 ， 产 生 的 话 单 量 为 200 万 条 ， 折 算 到 每 秒 ， 
产生 的 话 单 量 约 为 555 条， 而 业务 高 峰 期 的 量 可 能 达到 5550 条 。 平 均 分 配 到 两 个 系统 中 ， 每 个 
系统 每 秒 要 处 理 近 3000 条 话 单 才能 确保 系统 不 出 问题 。 由 于 系统 中 有 内 存 缓冲 区 ， 可 以 进行 一 
定 程 度 的 平滑 高 峰 处 理 ， 因 此 开发 商 认 为 ， 只 要 能 够 达到 每 秒 2000 条 话 单 以 上 的 处 理 能 力 ， 就 
可 以 保证 不 丢失 话 单 ， 而 目前 的 测试 结果 显示 ， 系 统 处 理 能 力 仅 能 达到 1500 条 。 这 就 意味 着 ， 
通过 优化 使 性 能 提升 50% ， 才 可 以 确保 万 无 一 失 ， 而 提升 23% 以 上 ， 只 能 基本 达到 最 低 要 求 。 仅 
仅 通过 调整 系统 参数 和 表 的 存储 参数 来 实现 这 个 目标 ， 确 实 具 有 一 定 的 挑战 性 。 

上 午 我 分 析 了 系统 的 主要 等 待 事件 ， 以 及 各 个 缓冲 区 的 情况 。 


Instance Efficiency Percentages (Target 100%) 


Buffer Nowait %: 99.98 Redo NoWait % 100.00 

Buffer Hit %: 99.69 In-memory Sort %: 99,97 

Library Hit 9: 99.79 Soft Parse %: 88.82 

Execute to Parse %: 98.61 Latch Hit %: 99.98 

Parse CPU to Parse Elapsd %: 93:32 % Non- Parse CPU: 98.51 
Shared Pool Statistics Begin End 


Memory Usage %: 93.70 95.50 
% SQL with executions»l: 35.14 34.34 


% Memory for SQL w/exec>l: 29.93 21.30 

Top 5 Wait Events 

A Wait % Tota 
Even Waits Time (cs) Wt Time 
db file parallel write 2,922 36, 456 47.99 
db file sequential read 16,401 15,874 20.90 
log file parallel write 8,824 10,812 14.23 
log file sync 2,907 5,169 6.80 
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direct path read 17,046 3,639 4.19 


从 主要 缓冲 池 的 指标 来 看 ， 没 有 明显 的 问题 。 而 从 主要 等 待 事件 上 看 ， 大 多 都 集中 在 和 IO 
相关 的 项 目 上 ,这 说 明 IO 系统 的 写 性 能 指标 并 不 好 。 另 外 , REDO LOG 相关 的 等 待 事件 占 整个 
等 待 事件 的 21%, REDO LOG 也 存在 优化 的 可 能 。 

从 STATSPACK 报告 上 看 ， 每 个 小 时 的 redo buffer allocation retries 为 483 次 ， 目 前 的 LOG 
BUFFER 为 1 MB， 加 大 LOG BUFFER 可 以 减少 这 方面 的 等 待 。 目 前 系统 共有 16 个 日 志 组， 每 
个 日 志 组 一 个 文件 ,每 个 文件 60MB。 从 日 志 切 换 情 况 来 看 ,今天 业务 高 峰 期 平均 1 分 钟 多 就 要 
切换 一 次 日 志 ， 由 于 无 法 查看 去 年 中 秋 节 期 间 的 数据 ， 因 此 我 只 能 推算 ， 如 果 业 务 量 加 大 10 (Ë, 
那么 每 隔 五 六 秒 就 会 产生 一 次 日 志 切 换 , 这 样 对 系统 的 性 能 会 产生 较 大 的 影响 。 因此 , 加 大 LOG 
BUFFER， 增 加 REDO LOG 文件 的 大 小 ， 使 性 能 提升 10% ~ 15% 还 是 很 有 可 能 的 。 

从 今天 的 STATSPACK 报告 中 ， 我 们 没有 看 到 明显 的 buffer busy waits 等 待 ， 一 个 小 时 只 有 
几 百 个 而 已 。 通 过 测算 ， 现 在 每 个 系统 每 秒 的 话 单 量 不 到 300 条 ， 而 每 个 插入 的 批 次 是 800 Ж, 
此 多 个 插入 进程 同时 插入 数据 的 机 会 较 少 ， 热 块 冲突 不 会 很 明显 ， 而 如 果 业 务 量 增加 10 P, 
那么 热 块 冲突 可 能 会 变 得 很 严重 。 目 前 A、B 两 套 系统 的 数据 库 版 本 分 别 是 8.1.7.4 ЯП 9.2.0.6, 都 
没有 使 用 ASSM。 通过 检查 发 现 ，FREELISTS 参数 都 是 默认 值 1, 这 对 于 并 发 插入 操作 会 有 较 大 
的 影响 。 加 大 FREELISTS 参数 ， 不 仅 可 以 减少 并 发 插入 时 分 配 空 块 的 等 待 ， 而 且 不 同 的 插入 进 
程 会 使 用 不 同 的 FREELISTS， 不 会 往 同 一 个 数据 块 中 插入 数据 ， 也 能 避免 不 同 的 插入 进程 之 间 
在 业务 高 峰 期 间 可 能 出 现 的 热 块 争 用 。 根 据 以 往 的 经 验 ， 如 果 FREELISTS 参数 设置 得 合理 ， 减 
少 了 这 方面 争 用 ， 可 能 带 来 的 性 能 提升 能 够 达到 5% ~ 10%。 

目前 核心 表 SM_HISTABLE 会 每 天 生成 一 张 独立 的 表 , 每 张 表 都 是 分 区 表 , 表 中 设置 了 一 个 
专门 的 分 区 字段 ID_HINT 进行 范围 分 区 ， 这 个 字段 的 值 是 循环 使 用 的 ,到 达 10000000 后 自动 回 
绕 为 1， 分 区 脚本 如 代码 清单 10-1 所 示 。 


代码 清单 10-1 


PARTITION BY RANGE (ID HI NT) 
) 


PARTITION PART_01 VALUES LESS THAN (1000000) 
OL OGGI NG 
TABLESPACE CQYDSMSC CENTERI 
PCTUSED 40 


PCTFREE 10 

NI TRANS 1 

AXTRANS 255 

STORAGE 
| NI TI AL 504K 
MI NEXTENTS 1 
MAXEXTENTS 2147483645 
FREELI STS 1 


FREELIST GROUPS 1 
BUFFER_POOL DEFAULT 
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这 种 分 区 模式 对 于 减少 热 块 冲突 帮助 不 大 ， 尽 管 在 调整 了 FREELISTS 参数 后 ， 热 块 冲突 的 
严重 程度 会 有 所 下 降 , 但 对 性 能 的 影响 不 会 特别 大 。 但 是 如 果 能 把 不 同 的 分 区 放 到 不 同 的 磁盘 组 
E, 那么 在 VO 负载 均衡 方面 , 使 用 HASH 分 区 的 作用 就 要 比 使 用 范围 分 区 更 为 明显 了 。 于 是 我 
马上 查阅 了 系统 底层 存储 的 设计 文档 ，A 系统 的 底层 存在 多 个 磁盘 组 : 


#1 磁盘 数 : 4 x36.4 RAID 类 型 : RAI D10 xps PV: hdisk2 FÆ VG: DATA1VG 
#2 磁盘 数 : 6 x36.4 RAID 类 型 : RAI D10 对 应 PV: hdisk3 [9 V6: DATA2VG 
#3 磁盘 数 : 6х36. 4 RAID 类 型 : RAI D10 对 应 PV: hdisk4 [9 VG: DATA3VG 
# ”磁盘 数 : 16 x36.4 RAID KA: RAI DIO 对 应 PV: hdisk5 FÆ VG: DATA4VG 
#5 磁盘 数 : 16 x36.4 RAID 类 型 : RAL D10 对 应 PV: hdisk8 FS VG: DATASVG 


B 系统 使 用 的 是 72 GB 的 磁盘 ， 由 20 块 磁盘 组 成 RAID 10, 在 VG 划分 时 进行 了 条 带 化 处 
理 。 在 底层 存储 的 设计 上 ,对 于 A 系 统 , 如 果 使 用 HASH HX, 可 以 将 IO 均匀 地 分 配 到 5 ЛТ 
组 上 ， 从 而 避免 业务 高 峰 期 的 IO 热点 。 根 据 以 往 的 经 验 ， 这 方面 的 调整 可 以 使 性 能 提升 10% ~ 
1596, 

在 ID_HINT 列 上 ,使 用 了 一 个 序列 (SEQUENCE JID. SEQ,3x 78 CACHE 设置 为 1000。 
一 般 来 说 ， 设 置 为 1000 就 够 用 了 ， 不 过 我 们 还 需要 进一步 测试 ， 看 看 将 CACHE 设置 得 更 高 是 
否 可 能 带 来 性 能 的 提升 。 

从 刚才 的 分 析 来 看 ， 目 前 可 以 达到 的 系统 性 能 提升 为 1-(1-0.1)x(l-0.05)x(l- 
0.1)=23%。 这 是 一 个 比较 保守 的 数字 ,实际 的 提升 比例 可 能 更 高 ， 因 此 通过 这 些 方面 的 调整 达到 
预定 的 优化 目标 还 是 很 有 可 能 的 。 

XERE, XF INSERT 操作 来 说 ,使 用 BULK INSERT 操作 可 以 大 幅度 提升 插入 的 性 能 ,不 
过 这 样 需 要 对 应 用 进行 较 大 的 修改 。 昨 天 在 讨论 方案 时 , 开发 人 员 认 为 要 在 短 时 间 内 完成 修改 比 
较 困难 ,但 鉴于 客户 也 希望 把 BULK INSERT 作为 最 后 的 解决 方案 , 他们 会 在 下 一 步 的 优化 工作 
中 进行 修改 ,但 是 不 列 和 人 本 次 优化 的 范围 。 

今天 是 在 分 析 问 题 的 过 程 中 度 过 的 , 感觉 过 得 很 快 。 快 下 班 的 时 候 ， 老 方 打 电话 过 来 , 说 飞 
机 在 武汉 晚点 ， 刚 到 北京 。 我 告诉 他 ， 经 过 一 天 的 分 析 ， 我 认为 通过 昨天 考虑 的 几 方 面 的 优化 ， 
使 性 能 提升 30% 还 是 可 以 实现 的 。 老 方 听 后 长 等 了 一 口气 , 在 飞机 上 他 党 得 自己 在 这 个 项 目的 售 
前 阶段 过 于 自信 ， 没 有 做 深入 的 分 析 ， 一 直 担心 最 终 不 能 让 客户 满意 。 

和 老 方 通 完 电话 ,我 给 客户 的 余 经 理 打 了 个 电话 , 问 她 能 不 能 安排 一 个 业务 不 是 很 忙 的 时 间 ， 
让 我 做 一 些 针对 性 的 实验 ， 以 便于 确定 优化 方案 。 余 经 理 说 这 是 一 个 后 台 系 统 , 我 可 以 随便 进行 
测试 ， 只 要 不 让 话 单 积 压 过 于 严重 ， 并 确保 话 单 不 丢失 就 可 以 了 。 于 是 我 连忙 联系 维护 工程 师 ， 
和 他 讨论 如 何 避 免 系统 话 单 积 压 。 维 护 人 员 说 他 们 本 身 就 有 一 个 实时 监控 系统 , 如果 话 单 缓冲 区 
占用 率 超过 60% ， 就 会 产生 告警 ,只 要 缓冲 区 保持 在 60% 以 下 ， 风 险 就 不 是 很 大 。 于 是 我 们 约定 
好 明天 白天 就 开始 进行 一 系列 实验 ,一 旦 系统 出 现 风险 ,他们 会 马上 通知 我 停止 实验 。 


11326Н 令 人 惊讶 的 结果 
最 近 系 统 的 业务 量 不 大 ， 所 以 客户 也 同意 我 们 白天 进行 测试 。 为 了 防止 误 操作 ， 客 户 把 
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SCOTT 账号 提供 给 我 。 今 天 准备 进行 以 下 几 个 测试 : 
O SEQUENCE 缓冲 区 测试 ; 
О 表 的 FREELISTS #1 ІМІТВАМЅ 参数 调整 的 测试 ; 
口 HASH 分 区 测试 ; 
а 提交 批量 测试 , 测试 批量 大 小 对 插入 性 能 的 影响 , 分 别 测试 批量 为 800、1500、3000、5000 
条 记录 的 响应 时 间 ; 
口 BULK INSERT 操作 测试 。 

进行 这 种 单条 SQL 执行 时 间 很 短 的 测试 ， 最 好 的 办 法 是 使 用 PROFILER 工具 ， 将 要 测试 的 
内 容 写 在 一 个 存储 过 程 里 ,通过 PROFILER 工具 来 计算 平均 执行 一 次 所 消耗 的 时 间 。 我 首先 为 
每 个 测试 项 目 都 编写 了 一 个 小 的 PL/SQL 过 程 ， 然 后 开 了 7 个 终端 ， 运行 这 个 存储 过 程 ， 在 第 8 
个 终端 上 的 测试 过 程 与 其 他 不 同 ， 增 加 了 PROFILER 的 脚本 ， 这 样 就 能 够 很 方便 地 采集 到 每 条 
SQL 的 执行 情况 了 。 

首先 测试 序列 ， 我 分 别 对 各 种 CACHE 值 进行 了 测试 ， 编 写 了 一 个 测试 用 的 存储 过 程 ， 如 代 
码 清 单 10-2 所 示 。 


代码 清单 10-2 


create or replace procedure testSeq(N integer) 
is 
i integer; 
b integer; 
v varchar2(20); 
begin 
ESL 
v:sto char(sysdate, ' уууу- тт- dd: hh24: mi :ss' ); 


dbms output.put line(v); 
loop 

exit when i>N; 

{лж +1; 

select smidseq.nextval into b from dual; 
end loop; 
v:sto char(sysdate, 'yyyy- тт- dd: hh24: mi :ss' ); 
dbms output.put line(v); 


end; 
I 


在 第 8 个 终端 上 ， 执 行 下 面 的 脚本 : 


declare 
err number; 
begin 
err:=DBMS_PROFILER.START_PROFILER (‘test seq 1000'); 
testseq( 200000); 
err: =DBMS PROFILER. STOP_PROFILER ; 
end; 
| 


脚本 执行 结束 后 ， 可 以 通过 代码 清单 10-3 所 示 的 脚本 查看 存储 过 程 中 每 一 行 执行 的 情况 。 
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代码 清单 10-3 


col umn RUN_COMMENT format a40 truncate 

select runid, run date, RUN COMMENT from plsql profiler runs order by runid; 
column unit name format al5 truncate 

column occured format 999999 

column line# format 99999 

column tot time format 999999,999999 


select p.unit name, p.occured, p.tot time, p.line# line, 
substr(s.text, 1,75) text 
rom 
(select u.unit name, d. TOTAL OCCUR occured 
(d.TOTAL TI ME/1000000000) tot time, d.line# 
from plsql profiler units и, plsql profiler data d 
where d. RUNI Dzu.runid and d. UNIT NUMBER = u.unit number 
and d. TOTAL OCCUR »0 
and u.runid= &RUN ID) p, 
User source s 
where p.unit name = s.name(+) and p.line# = s.line (+) 
order by p.unit пате, р. 1 і пе#; 


其 中 ， 参 数 run_id 来 自 于 plsql_profiler_units， 这 里 可 以 通过 我 们 执行 PROFILER 时 使 用 的 
名 称 来 查找 刚才 测试 对 应 的 run_id。 一 般 来 说 ， 还 有 一 种 更 简单 的 查找 方法 ， 就 是 找 最 后 一 个 
run_id， 因 为 гип іа 是 通过 序列 产生 的 ， 我 们 刚刚 做 过 的 测试 肯定 是 最 后 一 个 。 

上 述 查 询 的 结果 如 下 : 


UNIT_NAME OCCURED TOT_TIME LINE TEXT 

<anonymous> 1 .000781 4 

<anonymous> 1 .009996 5 

«anonymous» 1 . 002121 6 

TESTLOG 1 .001145 6 i: =0; 

TESTLOG 50001 40.602085 8 exit when i »zN 

TESTLOG 50000 59. 097742 9 i: =i +1 

TESTLOG 50000 2948.819922 10 select smidseq.nextval into v from dual 


PROFILER 可 以 计算 出 每 一 行 执行 的 次 数 ， 以 及 总 共 消 耗 的 时 间 ， 从 而 为 我 们 提供 准确 的 测 
试 数据 。SEQUENCE 缓冲 区 的 测试 结果 如 表 10-1 所 示 。 


表 10-1 
CACHE 并 发 数量 执行 次 数 测试 时 间 (Ж) 平均 每 次 执行 时 间 
2 8 200001 942122 4.7 
100 8 200001 73282 0.366 
1000 8 200001 48250 0.241 
5000 8 200001 47129 0.236 
20000 8 200001 43299 0.216 
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从 测试 结果 来 看 ，SEQUENCE 缓冲 区 的 增加 可 以 提高 其 访问 性 能 ,不 过 超过 1000 后 ， 再 加 
大 CACHE 参数 ， 性 能 提升 幅度 不 大 。 由 于 目前 已 经 达到 了 1000， 因 此 不 需要 再 加 大 了 。 

第 一 项 测试 结果 虽然 也 在 预料 之 中 , 但 还 是 让 我 感到 有 点 失望 。 哪 怕 能 提升 2% 、3% 也 是 好 
的 啊 ， 看 样子 只 能 寄 希 望 于 后 面 的 测试 项 目 了 。 第 二 项 测试 的 是 sm_histable 表 的 核心 参数 ， 测 
试 比 对 的 是 一 张 完全 按照 目前 参数 创建 的 测试 表 ， 和 修改 了 FREELISTS 、INITRANS INITIAL, 
NEXT 这 几 个 参数 的 测试 表 。 表 的 分 区 方式 ， 以 及 存储 的 表 空 间 等 属性 都 没有 修改 ,索引 也 完全 
按照 生产 环境 创建 。 这 次 测试 的 结果 让 人 感到 十 分 停放， 如 表 10-2 所 示 。 


ж 10-2 
项 目 相关 业务 VARA CRD) WE (RD) 对 比 说 明 
整体 时 间 短信 历史 记录 应 用 : — 128.67 112.35 ЖЕЛ. 14.53% 
DB_DaeMon 程 序 
平均 每 条 记录 的 插入 时 间 0.002573 0.002247 速度 提升 : 14.5396 


调整 这 几 个 参数 后 ,并 发 插入 的 性 能 居然 提升 了 14.5%， 这 有 点 出 乎 我 的 预料 ， 基 本 上 达到 
了 我 预期 的 最 高 值 。 兴 奋 之 余 ， 我 马上 进行 了 HASH 分 区 的 测试 ， 修 改 了 这 张 表 的 定义 ， 将 表 
分 区 从 10 个 修改 为 8 个 ， 分 别 存储 在 4 个 表 空 间 上 ， 这 4 个 表 空 间 分 别 属于 不 同 的 RAID 组。 
我 并 没有 将 5 个 RAID 组 全 部 使 用 ， 因 为 在 另外 一 个 RAID 组 上 ,存放 了 REDO LOG 文件 ， 这 
样 设 计 是 为 了 达到 REDO LOG 和 数据 文件 互 不 干扰 的 目的 。 


PARTITION BY HASH (ID HI NT) 
PARTITIONS 8 
STORE IN (CQYDSMSC_CENTER1, CQYDSMSC_CENTER2, CQYDSMSC CENTER3, CQYDSMSC CENTER4) 


测试 的 结果 如 表 10-3 所 示 。 


表 10-3 
项 А 相关 业务 调整 前 〈 秒 ) 调整 后 〈 秒 ) 对 比 说 明 
整体 时 间 短信 历史 记录 应 用 : 90.397 78.793 在 存储 参数 提升 14.53% 的 基 
DB_DaeMon 程 序 础 上 ,再 提升 14.73% 
平均 每 条 记录 的 插入 0.00181 0.00158 在 存储 参数 提升 14.53% 的 基 
时 间 础 上 ,再 提升 14.73% 


仅 这 两 项 优化 ,性 能 总 体 的 提升 就 已 经 达到 了 27%, 这 大 大 出 乎 了 我 的 意料 。 按 照 以 上 测 
试 结果 , 仅 依 靠 这 两 项 调整 , 就 可 以 完成 这 个 项 目 了 。 刚才 这 两 项 测试 都 是 在 A 系统 上 进行 的 ， 
我 又 在 B 系统 上 进行 了 相同 的 测试 ,测试 结果 也 令 人 满意 ， 表 核心 参数 调整 后 性 能 提升 了 
15.5% ， 不 过 第 二 项 HASH 分 区 的 性 能 提升 没有 A 系统 高 ， 只 有 10.27% ， 但 是 总 体 性 能 提升 
也 接近 了 24%. 

上 午 的 实验 时 间 过 得 很 快 ， 不 知 不 觉 已 经 快 一 点 钟 了 ， 突 然 感 觉 周 疙 静 悄 悄 的 ， 搭 眼 一 看 ， 
刚才 还 坐 了 30 多 人 的 办 公 室 里 除了 我 已 经 没有 别人 了 。 这 个 时 候 才 感觉 有 点 俄 ， 于 是 放下 正在 
进行 的 实验 ， 出 去 吃饭 。 在 路 上 , 我 还 在 回味 着 刚才 的 实验 ,心情 十 分 兴奋 。 突 然 看 到 路 边 有 个 
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麻辣 溪 的 扒 子 ， 想 想 吃 饭 的 地 方 离 这 里 还 挺 远 ， 不 如 就 随便 在 小 扒 上 上 吃 点 ， 回 去 继续 完成 实验 。 
说 实在 的 ， 我 对 重庆 的 麻辣 风味 还 是 不 太 习 惯 ,， 吃 了 一 小 盘 就 觉得 舌头 都 已 经 彻底 麻木 了 。 


回 到 办 公 室 ， 我 碰 到 了 现场 工程 师 ， 问 他 上 午 系统 是 否 有 异常 ， 他 说 并 没有 发 现 什么 


=: 
FF rh o 


听 到 这 样 的 消息 ， 我 的 心 就 更 踏实 了 。 上 午 每 次 测试 的 时 间 都 持续 了 近 20 分 钟 ， 如 果 这 对 主 生 


产 系统 产生 的 影响 不 大 ， 就 说 明 整 个 系统 的 处 理 能 力 是 足够 的 。 


下 午 的 测试 没有 取得 太 多 的 成 果 ， 尽 管 我 将 一 个 搬入 任务 的 记录 数 从 800 条 一 直 提 升 到 了 
5000 条 ， 但 对 性 能 的 提升 却 微乎其微 ， 原 本 以 为 搬入 任务 的 记录 数 在 这 套 系统 中 是 通过 参数 控 


制 的 ， 可 以 不 修改 程序 就 进行 调整 ,但 现实 情况 似乎 并 不 是 这 样 。 根 据 我 以 往 的 经 验 , 一 次 提交 


的 记录 总 数 有 一 个 最 优 值 ,一般 在 这 个 最 优 值 下 加 大 记录 数 ， 总体 插 入 性 能 会 有 所 提高 , 但 超过 


这 个 最 优 值 ， 插 和 性 能 反而 会 逐渐 下 降 。 这 个 最 优 值 和 数据 库 的 整体 情况 以 及 参数 配置 、REDO 
LOG 性 能 等 相关 。 在 一 般 情 况 下 ， 这 个 值 应 该 是 超过 1000 的 。 看 样子 技术 人 员 在 系统 上 线 前 已 
经 做 了 充分 的 测试 ， 选 择 了 一 个 相对 合理 的 值 ， 因 此 在 这 一 点 上 ， 确 实 没 有 多 大 的 优化 余地 了 。 


于 是 ， 我 接着 进行 了 BULK INSERT 操作 的 测试 。 根 据 以 往 的 经 验 ，BULK INSERT 对 于 性 


能 的 提升 是 很 大 的 。 由 于 BULK INSERT 只 是 作为 今后 改进 的 建议 , 不 作为 本 次 优化 的 重点 ， 


此 原本 考虑 仅 通过 调整 BULK INSERT 就 达到 优化 目标 的 想法 也 只 能 


BULK INSERT 的 测试 脚本 ， 如 代码 清单 10-4 所 示 。 


BY 
BY 
BY 
BY 
BY 


BI NARY_I NTEGER; 
BI NARY_I NTEGER 
BI NARY_I NTEGER 
BI NARY_I NTEGER; 
BI NARY_I NTEGER; 


作罢 了 。 我 编写 了 一 个 


代码 清单 10-4 
CREATE OR REPLACE PROCEDURE TESTFORALL (N INTEGER 
|5 
TYPE T SM ID S TABLE OF NUMBER( 10) | NDEX 
TYPE T SM SUBID IS TABLE OF NUMBER( 3) | NDEX 
TYPE T ORGADDR 15 TABLE OF VARCHAR2(21) INDEX 
TYPE T DESTADDR 15 TABLE OF VARCHAR2(21) INDEX 
TYPE T ID HINT 15 TABLE OF NUMBER( 10) INDEX 
V SM ID T. SM ID; 
V SM SUBI D T.SM SUBI D 
V ORGADDR T ORGADDR 
V DESTADDR T DESTADDR 
V 1D HI NT T ID HI NT; 
| | NTEGER 
BEGIN 
FOR 1 
LOOP 
V_SM_ID(1): =l; 
V SM SUBI D 1212; 
V ORGADDR(I):z'444555565'; 
V DESTADDR(IJ:2'555555'; 
SELECT SM I DSEQ. NEXTVAL INTO V ID HI NT(I) FROM DUAL; 
END LOOP; 
FOR | IN 1..N LOOP 
INSERT INTO SM HI STABLEO101 (SM 10, SM SUBI D, ORGADDR, DESTADDR, ID HI NT) VALUES 
(V. 5 D(I), V SM SUBID(I1), V ORGADDR(I),V DESTADDR(I),V ID HI NT(IJ) 


END LOOP; | 
COMMI Т; 
FORALL | IN 1.. 
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INSERT INTO SM_HISTABLEO101 (SM 10, SM SUBI D, ORGADDR, DESTADDR, ID HI МТ) VALUES 
(V SM 1D(I), V SM SUBID(I), V ORGADDR(I), V DESTADDR(I),V ID HI NT(I)); 
COMMI T; 
END; 
I 


测试 结果 不 出 所 料 ， 性 能 提升 了 数 倍 ， 如 表 10-4 所 示 。 


表 10-4 
项 目 相关 业务 调整 前 〈 秒 ) 调整 后 〈 秒 ) 对 比 说 明 

整体 时 间 短信 历史 记录 应 用 : DB_DaeMon 0.149 0.0389 速度 提升 3.83 倍 
程序 (A 系统 ) 

平均 每 条 记录 的 插入 时 间 0.000186 0.000048 ”速度 提升 3.83 倍 

整体 时 间 短信 历史 记录 应 用 : DB_DaeMon 0.0911 0.0247 速度 提升 3.68 倍 
程序 (BAS) 

平均 每 条 记录 的 插入 时 间 0.0001138 0.000031 ”速度 提升 3.68 倍 


做 完 实 验 ， 刚 刚 下 午 三 点 多 。 我 联系 了 余 经 理 ， 把 实验 的 结果 告诉 了 她 。 她 听 后 十 分 高 兴 ， 
建议 马上 开会 ， 如 果 测 试 的 结果 得 到 确认 ， 明 天 就 可 以 调整 表 结 构 ， 测 试 性 能 。 

我 马上 用 刚才 的 测试 数据 做 了 一 个 简单 的 PPT, 赶 到 会 议 室 已 经 快 四 点 了 , 余 经 理 和 工程 师 
正在 会 议 室 里 等 着 我 。 看 到 我 演示 的 结果 ， 他 们 都 十 分 兴奋 。 由 于 这 套 系统 使 用 了 日 表 ， 因 此 只 
要 重建 明天 使 用 的 表 就 可 以 完成 优化 工作 了 。 为 了 确保 安全 , 后 天 和 以 后 的 表 暂 时 不 做 调整 ， 等 
明天 使 用 结果 出 来 后 再 决定 是 否 统一 修改 日 表 创建 的 脚本 。 
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昨天 晚上 调整 了 表 结 构 ,我 建议 对 REDOLOG 也 相应 做 些 调整 ,目前 A 系统 的 LOG BUFFER 
Æ 1MB, REDO LOG 文件 大 小 是 61 МВ; B 系统 的 LOG BUFFER 是 120 KB, REDO LOG 文件 
大 小 是 100MB, 并且 B 系统 的 每 个 日 志 组 有 两 个 成 员 。 对 于 这 种 REDO 量 十 分 高 的 系统 ， 使 用 
两 个 成 员 虽 然 增 加 了 可 靠 性 , 但 是 对 性 能 的 负面 影响 也 是 很 大 的 。 因此 我 建议 将 B 系统 的 КЕРО 
LOG 成 员 改 为 1 个 。 

昨 晚 调整 建 表 脚 本 的 同时 ， 我 还 针对 数据 库 进行 了 一 些 调整 ， 其 中 对 SGA 和 REDO 的 调整 
如 表 10-5 所 示 。 


表 10-5 
= "U 当 前 值 建 议 值 设置 原则 
DB CACHE SIZE NP:3072M RH:2048M NP:4096M 对 于 本 系统 ， 在 内 存 充 足 的 情况 下 ， 设 置 
RH:2048M DB Cache， 尽 量 使 DB BUFFER 的 命中 率 提 


高 。 如 果 B 系 统 扩容 后 内 存 充足 ， 增 加 DB 
Cache 的 大 小 , 可 以 提高 查询 和 单条 INSERT 
的 性 能 (如 不 使 用 FORALL 操 作 ) 

DB KEEP SIZE 未 设置 NP:300M RH:300M 将 HISTABLE 以 外 的 常用 对 象 放 入 KEEP 池 
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( 续 ) 
ә WU 当 前 值 е х {Н 设置 原则 
LOG BUFFER NP: 1024000 RH: NP:20M RH:20M 设置 LOG BUFFER 的 原则 是 使 系统 在 忙 时 
124416 不 出 现 log buffer space 等 待 
SHARED POOL SIZE NP: 314572800 RH: NP:400M RH:400M 设置 比较 合理 的 时 候 , 不 会 出 现 较 多 的 库 缓 
318767104 存 和 SHARED POOL 门 锁 等 待 
REDO LOG 文 件 NP:61M RH:100M 2000M 业务 高 峰 期 ， 减 少 日 志 切 换 


A 系统 的 REDO LOG 文件 以 前 存放 在 HDISK2 E, ij UNDO, TEMP 以 及 一 部 分 索引 所 在 


的 表 空 间 也 使 用 了 HDISK2 ， 为 了 减少 IO 方面 的 争 用 ， 应 将 这 些 索引 存放 在 其 他 表 空 间 上 ， 同 
时 把 UNDO 表 空 间 移 到 HDISK3 Е. 


对 于 SM_HISTABLE 参数 做 了 如 下 调整 。 
A 系统 和 В 系统 的 SM_HISTABLE 表 的 存储 参数 设置 建议 如 表 10-6 所 示 。 


# 10-6 
参数 x 前 ff 建 议 ff 说 明 
FREELISTS 1 8 不 小 于 最 大 并 发 插入 进程 的 数量 
INITIAL 64 KB 8 MB 
NEXT 64 KB 8 MB 
INITRANS 未 设置 8 


A 系 统 和 B 系统 的 SM_HISTABLE 表 索 引 的 存储 参数 设置 建议 如 表 10-7 所 示 。 


表 10-7 
参数 4 前 {Н 建 议 值 说 n 
FREELISTS 1 8 不 小 于 最 大 并 发 插入 进程 的 数量 
INITIAL 64 KB 4MB 最 小 设置 为 2 MB 
NEXT 64 KB 4MB 最 小 设置 为 2 MB 
INITRANS 未 设置 8 


昨 晚 停 了 1 个 小 时 数据 库 , 还 好 开发 人 员 设 计 的 短信 平台 很 灵活 ,数据 库 停止 后 , 所 有 的 话 单 


被 暂 存 在 内 存 中 , 内 存 缓冲 区 存 满 后 会 转 储 到 文件 中 , 因此 停 数据 库 对 短信 业务 并 无 影响 。 数 据 库 
重启 后 ， 这 些 短信 话 单 被 集中 写 人 ， 事 后 经 过 业务 部 门 的 确认 ， 最 高 峰 时 ，A 系统 和 B 系统 短信 
话 单 的 插入 数量 达到 了 惊人 的 5800 条 / 秒 ， 而 从 系统 监控 上 看 ，CPU 负载 不 到 50%, VO 负载 也 只 
有 40% 左 右 ， 系 统 还 是 有 很 大 潜力 的 。 以 这 样 的 性 能 情况 来 看 ， 这 个 项 目 应 该 可 以 圆满 结束 了 。 


按照 以 往 的 惯例 ,做 完 实 施 后 的 第 二 天 我 一 大 早 就 到 了 客户 现场 ,系统 运行 得 很 平稳 ，CPU 


使 用 率 在 209604 F, VO 负载 也 很 小 。 这 是 我 意料 之 中 的 事情 ， 于 是 我 打 电 话 和 余 经 理 通报 了 一 


下 今天 的 情况 ， 然 后 进行 了 两 项 测试 ， 第 一 项 是 创建 一 张 和 原 来 一 样 的 表 ， 测 试 调整 了 REDO 


后 ， 


性 能 有 多 大 的 提升 ， 测 试 结果 让 我 感到 十 分 惊讶 ， 如 表 10-8 所 示 。 
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表 10-8 

基线 1 (RUNID 10) 模拟 目前 A 系统 的 REDO LOG 设 置 
指标 或 参数 数值 备注 
LOG BUFFER 1000 KB 
日 志 组 数量 8 
日 志文 件 大 小 60000 KB 
表 分 区 方式 范围 
执行 次 数 50000 
执行 时 间 37968 
平均 每 个 INSERT 的 时 间 0.75936 
日 志 切 换 时 间 11 
主要 等 待 事件 log buffer space 

buffer busy wait 

log Sync 
基线 2 (RUNID 11) 根据 Oracle 建 议 优化 后 的 测试 基线 
指标 或 参数 数值 备注 
LOG BUFFER 20 MB 
日 志 组 数量 3 
日 志文 件 大 小 1500 MB 
表 分 区 方式 范围 
执行 次 数 50000 
执行 时 间 24189 
平均 每 个 INSERT 的 时 间 0.48378 提高 57% 
日 志 切 换 时 间 5 分 钟 
主要 等 待 事件 buffer busy wait 


本 次 测试 模拟 了 实际 生产 环境 中 写 和 人 进程 的 工作 , 先 启动 7 个 插 和 人 进程 进行 插入 操作 , 在 第 
8 个 进程 中 使 用 PROFILER 进行 跟踪 ， 每 个 批 次 插入 800 条 记录 ,循环 50000 次 。 优 化 前 和 优化 
后 的 性 能 对 比 十 分 惊人 ， 居 然 达 到 了 57% ， 这 是 我 没有 预想 到 的 。 后 来 我 又 在 B 系统 上 做 了 同 
样 的 测试 ， 虽然 性 能 提升 没有 A 系统 那么 明显 ， 不 过 也 达到 了 38%。 
我 马上 给 北京 的 老 方 打 了 个 电话 ， 告 诉 他 这 里 的 优化 效果 。 老 方 感到 十 分 惊讶 ， 这 个 项 目 
真 可 谓 是 柳暗花明 ， 原 本 以 为 很 难 搞定 的 项 目 居然 通过 简单 地 调整 了 一 些 参数 就 取得 了 这 么 大 
的 效果 。 

下 午 的 总 结 会 上 ， 大 家 的 心情 都 很 不 错 。 小 余 望 着 窗外 久违 的 阳光 说 :“ 按 理 说 ， 这 么 好 的 
天 气 就 不 该 上 班 了 , 应 该 找 个 茶馆 喝 茶 去 。” 大 家 听 完 都 乐 了 。 我 说 :“ 我 们 干脆 找 个 茶馆 开会 算 
了 。” 任 务 完成 得 不 错 ， 大 家 的 心情 当然 就 好 了 。 

这 个 优化 项 目 很 成 功 , 第 二 年 除夕 的 时 候 , 我 收 到 了 小 余 的 一 条 短信 :“ 今 天 系统 一 切 正常， 
谢谢 你 ， 视 你 新 年 愉快 。” 春节 时 收 到 千里 之 外 的 祝福 ， 确 实 是 件 很 恢 意 的 事情 。 


理解 索引 


RETA? AMARA DBA 都 没有 彻底 理解 索引 的 真正 含义 。 为 什么 有 时 候 通 过 索引 访问 
一 张 表 会 比较 快 呢 ? 想 要 回答 这 些 问 题 ， 需要 从 头 了 解 索 引 到 底 是 什么 。 大 家 小 时 候 应 该 都 用 过 
新 华 字 典 ， 它 是 按照 拼音 字母 排序 的 ， 因 此 查 字 典 时 可 以 通过 汉字 的 拼音 来 查找 。 最 简单 的 方式 
是 根据 拼音 字母 的 大 体位 置 先 随便 翻 开 一 页 , 然后 根据 这 一 页 的 内 容 再 次 翻 页 , 直到 找到 这 个 汉 
字 。 这 种 翻 字典 的 方式 有 点 土 ， 速度 也 比较 慢 , 不 过 这 是 我 们 使 用 的 一 种 最 原始 的 索引 方式 。 为 
了 提高 查 字 典 的 速度 , 我 们 一 般 都 会 在 字典 侧面 标 出 某 个 字母 所 在 的 位 置 , 这样 就 可 以 首先 根据 
字母 所 在 的 位 置 , 更 为 精确 地 判断 某 个 字 可 能 的 位 置 。 这 种 包含 两 级 的 索引 , 加 快 了 定位 的 速度 。 

实际 上 ，Oracle 的 索引 访问 和 刚才 看 到 的 翻 字典 是 类 似 的 。Oracle 的 索引 是 一 种 B 树 结构 ， 
学 过 《数据 结构 》 这 门 课 的 朋友 可 能 对 了 B 树 比较 熟悉 ， 既 然 是 树 ， 就 应 该 有 树 根 、 树 枝 和 树叶 。 
对 一 棵 树 的 访问 肯定 要 从 根 出 发 ， 然 后 经 过 树枝 ， 最 终 到 达 树 叶 ， 如 图 11-1 所 示 。 


索引 记录 


1 i V^ 
A 24 
[g^ [EU] 索引 记录 头 
wv 
页 €^ ENS 键 什 字段 长 度 
Л 键 值 
[О] ROWID 
11-1 


如 果 我 们 要 查找 一 条 ID=3 的 记录 , 而 在 ID HR LARS, 那么 就 可 以 通过 索引 ， 直 接 找 到 
ID=3 的 所 有 索引 项 ， 然 后 根据 这 些 索引 项 逐条 从 表 中 找 出 所 有 需要 的 字段 ， 这 就 是 常见 的 索引 
访问 方式 。 
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从 索引 的 原理 可 以 看 出 , 通过 访问 索引 可 以 提高 系统 的 访问 速度 。 但 是 通过 索引 访问 就 一 定 
会 提高 性 能 吗 ? 答案 当然 是 否定 的 。 大 家 都 知道 数据 库 访 问 数 据 的 主要 开销 分 为 WO 开销 和 CPU 
开销 两 部 分 。 通 过 一 次 需要 访问 的 数据 块 的 总 数量 ， 就 可 以 初步 判断 出 操作 的 大 体 开 销 。 如 果 有 
一 个 查询 ， 需 要 查 出 一 张 有 3000 万 记录 的 表 中 的 2000 万 条 记录 , 那么 通过 索引 访问 这 张 表 可 能 
就 会 比 直接 对 这 张 表 做 全 表 扫 描 慢 许多 。 鉴 于 索引 访问 的 这 个 特点 , 我 们 不 能 想当然 地 认为 索引 
访问 就 是 好 的 。 

从 上 面 的 讨论 我 们 已 经 知道 了 , 索引 其 实 并 不 神秘 , 它 只 是 存储 在 数据 库 里 的 树 状 结构 的 数 
据 , 我 们 可 以 通过 这 些 数据 提高 某 些 表 访问 的 性 能 。 那么 下 一 个 问题 就 是 怎么 在 应 用 中 设计 合理 
的 索引 ， 从 而 达到 最 好 的 效果 呢 ? 可 能 有 朋友 要 说 了 ， 既 然 索 引 有 这 么 好 的 效果 , 那么 给 每 个 字 
段 都 创建 一 个 索引 不 就 可 以 了 。 刚 才 我 们 说 了 , 索引 是 数据 库 中 的 一 种 特殊 存储 结构 ， 当 表 中 的 
数据 变化 时 , 索引 是 必须 做 同步 更 新 的 ,因此 索引 带 来 的 并 不 仅仅 是 查询 性 能 的 提升 ， 还 会 带 来 
一 个 副作用 : 索引 的 更 新 是 需要 成 本 的 , 过 多 的 索引 可 能 会 带 来 对 写 和 人 操作 性 能 的 负面 影响 。 基 
于 这 个 原理 ,我 们 在 设计 索引 时 需要 统筹 考虑 ， 尽 可 能 用 最 少 的 索引 达到 最 佳 的 效果 。 事 实 上 ， 
应 用 系统 在 设计 索引 时 ,只 有 很 少 的 索引 是 经 统筹 考虑 后 创建 的 , 大 多 数 索引 都 是 系统 运行 过 程 
中 随意 添加 的 。 一 个 系统 长 时 间 运 行 后 ,系统 中 的 索引 就 十 分 混乱 了 。 我 在 做 性 能 优化 时 经 常会 
碰 到 一 些 表 存在 大 量 的 索引 ， 五 六 个 算 少 的 ， 多 时 能 达到 十 多 个 。 这些 索 引 都 是 在 出 现 了 一 些 性 
能 问题 后 , 为 了 单一 解决 某 个 问题 而 添加 的 。 一 张 表 中 存在 这 么 多 的 索引 , 仅 维 护 索引 所 增加 的 
那些 开销 已 经 不 能 解决 问题 了 。 最 为 关键 的 是 这 些 表 上 还 存在 很 多 与 索引 字段 相近 的 索引 , 系统 
经 常会 由 于 分 析 数 据 不 准确 而 出 现 索引 选择 错误 的 现象 ， 从 而 导致 系统 性 能 极为 不 稳定 。 

在 这 里 , 我 又 想到 了 一 个 十 分 著名 的 问题 , 一 张 表 上 到 底 设 计 多 少 个 索引 比较 好 ? 经常 有 朋 
友 问 我 这 个 问题 , 而 且 也 有 很 多 文章 和 书籍 给 出 了 十 分 明确 的 数字 一 一 一 张 表 上 最 好 不 超过 6 个 
索引 。 但 我 不 知道 这 个 数字 是 怎么 得 出 的 ,因为 我 从 来 没有 在 任何 官方 资料 或 者 学 术 性 论文 中 看 
到 过 这 样 的 描述 。 好 像 TOAD 里 有 一 个 简单 的 数据 库 健康 检查 工具 ， 其 中 有 一 项 是 检查 索引 超 
过 6 个 的 表 ， 也 许 某 些 DBA 就 认为 超过 6 个 索引 的 设计 可 能 是 有 问题 的 ， 而 少 于 6 个 一 般 不 会 
有 问题 。 实 际 上 仅 用 这 个 数字 来 判断 索引 设计 是 否 合理 是 十 分 不 恰当 的 , 我 曾经 见 到 过 存在 十 多 
个 索引 的 表 , 但 是 这 些 索引 都 是 必需 的 ; 也 有 些 表 只 有 两 三 个 索引 , 但 是 索引 的 设计 却 存 在 问题 。 
我 想 TOAD 中 的 这 个 工具 只 是 为 了 提醒 大 家 系统 中 一 些 表 上 的 索引 过 多 ， 需 要 检查 索引 设计 是 
否 合理 ,而 并 不 是 将 6 个 索引 作为 判断 合理 性 的 分 界线 。 另 外 要 说 明 的 一 点 是 ,虽然 索引 会 增加 
维护 的 成 本 ， 影 响 DML 语句 的 性 能 ， 但 是 在 一 般 的 OLTP 系统 中 ， 和 DML 操作 相 比 ，SELECT 
操作 所 占 的 比例 要 高 得 多 , 大 多 数 系统 中 这 一 比例 都 高 达 80%, 有 的 甚至 能 达到 9096, 在 这 种 系 
统 中 ， 如 果 少 一 个 索引 ， 可 能 导致 某 张 大 表 经 常 进行 全 表 扫 描 ， 增 加 的 CPU 和 VO 开销 可 能 达 
到 这 个 索引 维护 成 本 的 几 十 倍 甚至 上 百倍 。 如 果 你 明白 了 这 一 点 ， 就 会 知道 判断 索引 是 否 合理 不 
仅仅 是 一 个 数字 这 么 简单 的 。 

一 般 分 析 索 引 是 否 合 理 的 方法 是 将 和 某 张 表 相关 的 SQL 都 查找 出 来 ,按照 BUFFER GET rk 
者 PHYSICAL READ 排序 ， 分 析 排 在 前 面 的 对 系统 性 能 影响 较 大 的 SQL， 从 中 找 出 WHERE Ж 
件 和 连接 条 件 , 从 而 判断 如 何 创建 索引 才 更 为 合理 。 这 是 一 项 十 分 艰苦 的 工作 , 不 仅仅 需要 技术 ， 
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更 需要 认真 的 态度 和 坚 蔬 的 精神 。 使 用 这 种 方法 得 出 的 索引 设计 原则 是 比较 合理 的 。 随 后 我 将 通 
过 案例 来 详细 介绍 分 析 索 引 的 方法 ， 这 里 暂 不 对 该 方法 进行 深入 的 讨论 。 


11.1 反 转 键 索 引 的 误区 


在 回顾 了 索引 的 一 些 基础 知识 后 , 我 们 需要 进一步 了 解 索引 优化 的 相关 知识 ,研究 索引 的 主 
要 种 类 以 及 各 类 索引 在 使 用 时 的 一 些 要 点 。 

首先 来 看 最 常见 的 В 树 索引 。B 树 索引 适用 于 几乎 所 有 的 场合 , 也 是 系统 中 使 用 最 为 广泛 的 
索引 形式 。 实际 上 , 我 们 所 说 的 普通 索引 、 反 转 键 索 引 、 降 序 索 引 、 函 数 索 引 等 都 是 В 树 结 构 的 ， 
其 物理 存储 结构 是 完全 相同 的 。 与 之 相对 的 位 图 索引 则 是 完全 不 同 的 存储 结构 , 位 图 索引 不 是 树 
状 结构 ， 没 有 枝 节 点 ， 只 有 叶 节 点 。B 树 索 引 操 作 包括 索引 唯一 性 扫描 、 索 引 范 围 扫描 、 快 速 索 
引 全 扫描 和 索引 全 扫描 , 而 位 图 索引 的 访问 方式 只 有 一 种 , 就 是 索引 全 扫描 。 在 使 用 位 图 索引 时 , 
只 有 对 索引 完全 扫描 一 遍 ， 才 能 找到 所 有 需要 的 行 。 

我 们 知道 ， 索 引 是 一 种 树 状 结构 ， 其 组 织 形式 是 一 棵 扩展 了 的 B 树 ， 和 普通 В 树 不 同 的 是 ， 
这 棵 了 B 树 的 所 有 叶 节 点 上 都 有 一 条 双向 链 , 称 为 叶 节 点 链 。 这 条 双向 链 是 根据 索引 键 值 的 大 小 进 
行 排序 的 , 它 的 存在 十 分 重要 ， 是 实现 索引 范围 扫描 最 关键 的 技术 。 当 进行 索引 范围 扫描 时 ， 首 
先 通 过 B 树 的 定位 算法 ,从 根 开始 ,找到 范围 扫描 起 始 键 值 的 位 置 ,然后 从 这 个 位 置 开 始 , 通过 
叶 节 点 链 按照 升序 或 者 降序 的 方式 扫描 相关 的 叶 节 点 ， 直 到 找到 超出 扫描 范围 的 键 值 为 止 。 

最 为 普通 的 索引 是 按照 键 值 升序 排列 的 , 索引 树 右 面 枝叶 的 键 值 总 比 左边 的 大 。 而 如 果 我 们 
设计 了 降序 索引 ， 那 么 情况 则 正好 相反 。 

函数 索引 是 一 种 特殊 的 B 树 索引 ,引入 函数 索引 的 目的 是 为 了 解决 那些 在 使 用 过 程 中 必须 在 
字段 上 做 函数 运算 的 情况 。 一 般 情 况 下 , 我 们 会 建议 开发 人 员 不 要 在 WHERE 条 件 中 的 表 字段 上 
使 用 函数 , 以 便 为 其 设计 索引 。 不 过 事实 上 , 我 们 无 法 杜绝 这 样 的 函数 存在 ,比如 在 某 些 情况 下 , 
必须 从 一 个 字段 取 第 2、3 位 进行 比较 : WHERE substr(id,2,2)='TD'， 如 果 这 样 的 查询 条 件 放 弃 函 
数 的 话 ,， 程序 员 的 处 理 将 十 分 复杂 。 函 数 索引 为 这 种 情况 提供 了 很 好 的 帮助 ,如 果 这 个 查询 条 件 
使 用 索引 效果 较 好 的 话 , 我 们 就 可 以 在 ID 字段 上 创建 一 个 以 函数 substr(id,2,2 ) 为 键 的 B 树 索 引 。 
事实 上 ,在 绝 大 多 数 应 用 系统 中 ， 函 数 索 引 都 是 不 可 避免 的 ,但 不 幸 的 是 ,在 我 做 过 的 优化 项 目 
中 ， 我 基本 上 没有 看 到 过 用 户 使 用 这 种 索引 。 

接 下 来 讨论 反 转 键 索引 (reverse key index )， 这 是 一 种 十 分 著名 的 索引 。 反 转 键 索引 在 存储 
键 值 时 ， 先 将 键 值 进行 翻转 ， 比 如 ，'1234' 存 储 在 索引 中 的 键 值 是 4321。 设 计 反 转 键 索 引 的 目的 
是 为 了 解决 索引 的 热 块 冲突 问题 。 索 引 块 出 现 热 块 冲突 是 我 们 在 性 能 优化 时 经 常会 碰 到 的 问题 ， 
比如 一 个 主键 是 通过 序列 生成 的 , 那么 主键 索引 就 可 能 成 为 热 块 ， 这 种 情况 下 ， 如 果 我 们 确定 针 
对 主键 的 查询 不 存在 或 者 很 少 有 索引 范围 扫描 , 那么 就 可 以 考虑 使 用 反 转 键 索 引 来 解决 主键 的 热 
块 冲突 问题 。 其 原理 很 简单 ,通过 键 值 的 反 转 , 打 乱 索引 数据 块 中 的 数据 组 织 ， 从 而 将 热点 数据 
分 散 到 不 同 的 索引 数据 块 中 。 

除了 解决 热 块 冲突 的 问题 外 ，DBA 界 还 流传 着 这 样 的 说 法 : 反 转 键 索 引 可 以 解决 like '%abc' 
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无 法 使 用 索引 的 问题 。 粗 想起 来 ， 确 实 是 这 样 ， 由 于 通配符 在 第 一 个 字符 ，like '%abc' 这 样 的 条 
件 无 法 进行 索引 范围 扫描 ， 因 此 一 般 情 况 下 使 用 全 表 扫 描 比 较 合适 。 不 过 在 某 些 特殊 情况 下 ,如 


果 表 规模 巨大 ,这 种 全 表 扫 描 的 成 本 会 很 高 ， 如 果 色 
键 值 时 是 反 转 过 来 的 ，labc,2abc 在 索引 键 中 的 存储 为 abcl,abc2， 这 种 情况 下 ， 可 以 通过 范围 扫 


<| 


6 使 用 索引 就 好 了 。 而 反 转 键 索引 正好 在 存储 


描 将 符合 条 件 的 记录 找 出 来 吗 ” 这 种 解释 似乎 是 很 合理 的 ， 我 也 曾经 被 这 种 理论 蒙蔽 过 一 段 时 
间 ， 直 到 有 一 天 我 自己 做 了 一 个 实验 ， 才 发 现 问题 远 非 那么 简单 。 下 面 就 来 回顾 一 下 这 个 实验 ， 


首先 创建 测试 表 : 


DROP TABLE TI NDEX 
CREATE TABLE TINDEX as SELECT DISTINCT 


d 


OPQRSTUVWXYZ1234456' abc 
rom dba objects; 
SERT TO TI NDEX SELECT DISTINCT 


OPQRSTUVWXYZ1234456' abc 
rom dba objects; 


OBJ ЕСТ NAME, OBJECT 10, OB) ECT TYPE, CREATED, STATUS, TEMPORARY, TI MESTAMP, ' ABCDEFGHI J KL 


OBJ ЕСТ NAME, OBJ ECT 10, OBJ ECT TYPE, CREATED, STATUS, TEMPORARY, TI MESTAMP, ' ABCDEFGHI J KL 


create index idx tindex name on tindex(object name ) reverse 


然后 做 一 次 表 分 析 : 


exec DBMS STATS.GATHER TABLE _ STATS(ownname=>' scott', tabname=>'tindex' 
estimate percent=>30, -cascade=>true, degree=>2) 


似乎 一 切 都 准备 好 了 ， 下 面 来 测试 反 转 键 索引 是 否 真 的 能 够 解决 like 语句 的 问题 : 


SQL> set autotrace traceonly 


select * froM tindex where object name like ' %TINDEX' 


SQL» 


Execution Plan 


Plan hash value: 2264840918 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | 
| 0 | SELECT STATEMENT | | 5297 |  553K| 103 (3)| 00:00:01 | 
|* 1 | TABLE ACCESS FULL | TINDEX | 5297 | 553K] 103  (3)| 00:00:01 | 


1 - filter("0BJ ECT МАМЕ" LIKE ' 4TI NDEX' 


1 recursive calls 
0 db block gets 
1717 consistent gets 
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0 physical reads 
0 redo size 
939 bytes sent via SQL*Net to client 
400 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
2 rows processed 


似乎 索引 并 没有 被 自动 使 用 ， 我 们 使 用 hint 强制 索引 来 看 看 : 


SQL» select /*+|NDEX(TINDEX idx tindex name ) */ * fromtindex where obj ect_name like 
' WTI NDEX' 


Execution Plan 


Plan hash value: 2021627753 


[19 | Operation | Name | Rows | Bytes | Cost (%CPU)| Time 

| 0 | SELECT STATEMENT | | 5297 | 553K | 5548 (1) |00:00:54 
| 1 |TABLE ACCESS BY INDEX ROW D| TI МЕХ | 5297 | 553K | 5548 (1) |00:00:54 
|*2 |I NDEX FULL SCAN || DX TI NDEX NAME| 5287 | | 520 (1) |00:00:05 
Predicate Information (identified by operation id): 


2 - filter(*0BJ ECT NAME" LIKE ' XTI NDEX' 


Statistics 
1 recursive calls 
0 db block gets 
520 consistent gets 
0 physical reads 
0 redo size 
939 bytes sent via SQL*Net to client 
400 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
2 rows processed 


这 里 虽然 使 用 了 索引 , 但 扫描 方式 是 全 索引 扫描 ， 而 不 是 我 们 期 待 的 索引 范围 扫描 。 看 来 反 
转 键 索引 并 不 能 解决 这 个 问题 。 我 们 继续 下 面 的 实验 : 


SQL» create index idx tindex func ontindex(reverse(0bject_namel)) 


Index created. 
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SQL» exec DBMS_STATS. GATHER_TABLE_STATS(ownname=>'scott', tabname=>'tindex' 
estimate_percent=>30, -> cascade=>true, degree=>2) 


PL/SQL procedure successfully completed 
SQL» select * fromtindex where reverse(object name) like ' ХЕРМ T% 


Execution Plan 


Plan hash value: 1286384425 


| Id [Operation | Na me | Rows |Bytes|Cost (%CPU)| Time 

| 0 [SELECT STATEMENT | 4 | 436 | 7 (0) | 00:00: 01| 
| 1 |TABLE ACCESS BY INDEX ROWI D| ТІ NDEX | 4 | 436 | 7 (0) 100: 00: 01| 
|* 2 || NDEX RANGE SCAN || DX ТІ МОЕХ FUNC| 4 | | 3 (0) |00:00:01| 


2 - access(REVERSE("0BJ ECT NAME") LIKE 'XEDNI Т 
filter(REVERSE("OBJECT_ NAME") LIKE 'XEDNI Tt 


Statistics 
1 recursive calls 
0 db block gets 
6 consistent gets 
0 physi cal reads 
0 redo size 
939 bytes sent via SQL*Net to client 
400 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
2 rows processed 


这 才 是 我 们 需 通过 reverse 图 数 ， 然 后 将 Y%TINDEX 反 转 为 XEDNIT%， 这 样 才能 
真正 解决 问题 ， 而 这 个 SQL 的 开销 是 原 SQL 的 几 百 分 之 一 。 实 际 上 ， 这 种 解决 方案 只 能 在 修改 
үү, 不 如 使 用 反 转 键 索引 那么 简单 、 用 途 广泛 ,不 过 我 们 也 终于 通过 实验 纠正 了 
流传 甚 广 的 错误 。 我 通过 搜索 引擎 查阅 了 大 量 关 于 此 话题 的 英文 资料 , 终于 明白 了 这 一 误解 的 来 
源 ， 最 初 ， 确 实 有 一 篇 文章 介绍 如 何 使 用 reverse 函数 来 解决 这 个 问题 : 


SELECT * 
FROM customer 
WHERE reverse(Cust Name) LIKE ' %sali V%' 


但 后 来 这 篇 文章 在 被 转载 时 ， 错 误 地 写成 了 : 


SELECT * 
FROM customer 
WHERE Cust Name LIKE ' %а і М% 
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以 此 为 蓝本 , 终于 引发 了 通过 反 转 键 索 引 优化 like 操作 这 个 错误 的 观点 。 由 此 可 见 , 不 经 过 
自己 验证 就 全 盘 吸 收 网 络 上 的 知识 是 多 么 危险 。 

不 过 Oracle 反 转 键 索引 的 存储 结构 ， 确 实 具备 对 Like 条 件 做 范围 扫描 的 基础 ， 这 种 扫描 和 
Oracle 以 往 提 供 的 任何 一 种 索引 扫描 技术 都 不 相同 , 是 一 种 全 新 的 索引 扫描 方式 。 也 许 在 Oracle 12 
或 者 13 版 本 中 , 真 的 会 出 现 类 似 的 功能 ，Oracle 的 每 个 新 版 本 给 大 家 带 来 的 惊喜 一 直 都 是 出 乎 姑 
多 数 人 意料 的 。 
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设计 索引 是 专业 性 很 强 的 工作 ， 一 般 来 说 ， 索 引 设计 最 好 有 专业 РВА 参与 ， 不 过 现实 中 ， 
绝 大 多 数 系统 的 索引 设计 都 是 由 开发 人 员 完 成 的 。 由 于 开发 人 员 对 索引 的 原理 不 甚 了 解 , 因此 大 
多 数 软件 系统 中 的 索引 设计 方面 都 存在 很 大 的 问题 。Oracle 公司 有 一 门 培训 课程 叫做 “开发 
DBA”， 这 门 课程 的 主要 目的 是 让 开发 人 员 理 解 一 些 Oracle 的 基本 原理 与 概念 ， 从 而 在 设计 应 用 
系统 时 依据 这 些 原 理 ， 避 免 出 现 严 重 的 问题 。 在 开发 人 员 中 进行 类 似 “ 开 发 DBA” 这 样 的 课程 
培训 ， 是 数据 库 优 化 工作 中 十 分 重要 的 环节 ， 而 这 个 环节 往往 被 我 们 所 忽视 。 实 际 上 ， 对 研发 团 
队 进 行 适当 的 培训 ， 可 以 节省 大 量 的 成 本 。 

本 节 要 讨论 的 话题 是 如 何 设 计 索 引 ， 这 是 很 多 DBA 都 想 了 解 的。 实际 上 ， 前 面 章 节 已 经 讨 
论 过 设计 索引 的 一 些 基 本 方法 。 索 引 的 设计 要 遵循 一 些 最 基本 的 原则 。 首 先 必 须 有 针对 性 ,索引 
的 目的 是 快速 定位 数据 ,因此 每 个 索引 都 必须 符合 快速 定位 数据 的 要 求 。 比 如 , 我 们 想 让 下 面 的 
这 条 语句 执行 得 更 快 一 些 ， 消 耗 更 少 的 资源 。 

select emp name,emp id,sal from emp where emp_id=11023 

首先 需要 分 析 emp 这 张 表 , emp 表 是 企业 的 职员 表 , 有 数 万 条 记录 ,而 每 个 职员 都 有 唯一 的 
emp id 对 应 ， 如 果 在 emp_id 上 创建 了 索引 ， 那么 这 条 SQL 就 可 以 通过 索引 快速 定位 到 emp. id, 
然后 通过 索引 中 的 ROWID 直接 找到 emp 表 中 的 相关 记录 ， 并 取出 所 需要 的 数据 。 这 种 情况 下 ， 
在 emp_id 上 创建 一 个 索引 就 是 十 分 必要 的 。 我 们 再 来 看 下 一 个 语句 : 

select emp id,sal from emp where emp_id=11023 and emp name like 'John% 

在 这 个 语句 中 ，WHERE 条 件 有 两 个 : 一 个 是 emp_id=11023 ， 另 外 一 个 是 emp. name like 
John%'。 这 时 Oracle 该 如 何 来 选择 合适 的 执行 计划 呢 ? 这 里 讨论 的 前 提 是 使 用 CBO 优化 器 
(КВО 优化 器 在 索引 选择 时 智能 程度 很 低 ， 出 现 执行 计划 错误 的 机 会 要 比 CBO 大 得 多 ， 因 此 建 
议 在 条 件 允 许 的 情况 下 ， 尽 可 能 使 用 СВО ), CBO 会 根据 索引 的 统计 数据 计算 每 个 索引 访问 路 
径 的 成 本 ， 从 而 选择 一 种 开销 较 小 的 执行 计划 。 在 这 个 案例 中 ， 如 果 通 过 emp. id 来 查找 相关 的 
数据 ，emp_id 就 是 主键 ， 根 据 emp_id=11023 可 以 唯一 定位 到 一 条 记录 ， 然 后 就 可 以 取出 这 条 
记录 中 sal, emp. name 和 emp. id 这 三 个 字段 的 值 ， 将 emp_name 字段 的 值 和 WHERE 条件 中 的 
emp. name like 'John%' 进 行 比较 ,如果 这 条 记录 符合 此 条 件 就 返回 该 记录 ， 如 果 不 符合 则 没有 记 
录 返 回 。 
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下 面 来 分 析 另 外 一 条 访问 路 径 。 如 果 使 用 emp_name 上 的 索引 , 首先 应 找 出 所 有 的 emp. name 
like John%' 记 录 ， 假 设 能 找到 10 条 ， 接 着 通过 索引 中 提供 的 这 10 条 记录 的 ROWID 去 访问 这 张 
K, fü emp id, sal 这 两 个 字段 的 值 取出 来 ， 然 后 再 通过 另外 一 个 过 滤 条 件 emp_id=11023 进行 得 
选 ， 把 符合 条 件 的 记录 找 出 来 。 很 明显 ， 这 条 访问 路 径 的 开销 要 比 第 一 条 略 高 ， 因 为 这 里 先 查 出 
了 10 条 记录 ， 然 后 又 通过 过 滤器 过 滤 掉 了 其 中 的 9 条 ， 而 第 一 种 执行 计划 只 检索 了 一 条 记录 就 
获得 了 结果 。 

第 三 种 访问 路 径 就 是 我 们 所 说 的 全 表 扫 描 。 如 果 我 们 在 emp name 和 emp id 上 都 没有 创建 
RIL, 那么 就 必须 对 这 张 有 几 万 条 记录 的 表 从 头 到 尾 扫描 一 遍 , 找到 所 有 符合 上 面 两 个 过 滤 条 件 
的 记录 ， 并 把 对 应 的 emp_id 和 sal 值 检索 出 来 。 

这 三 条 访问 路 径 到 底 哪 个 开销 更 小 呢 ? 实际 上 ，Oracle 的 CBO 优化 器 会 自动 计算 访问 路 径 
的 成 本 ， 并 且 选 择 最 佳 路 径 来 执行 这 条 SQL。 上 例 中 包含 了 Oracle 访问 数据 的 三 种 常见 的 方法 。 
第 一 种 是 索引 唯一 性 检索 ， 通 过 唯一 性 索引 定位 到 某 条 记录 ， 读 出 该 记录 后 通过 emp пате 这 个 
过 滤 条 件 进 行 筛选 ， 最 后 获得 符合 条 件 的 所 有 记录 。 第 二 条 路 径 是 通过 emp. name 上 的 索引 找 出 
所 有 符合 条 件 的 记录 , 这 种 查找 方式 是 找到 符合 条 件 的 第 一 条 记录 , 然后 顺 着 叶 节 点 链 按照 升序 
或 者 降序 的 方式 扫描 出 所 有 符合 条 件 的 记录 的 ROWID ， 再 依次 将 表 中 的 相关 数据 块 读 出 来 ， 根 
据 其 他 的 过 滤 条 件 进行 筛选 ,最 后 找到 符合 条 件 的 记录 , 这 种 方式 就 是 我 们 常 说 的 索引 范围 扫描 。 
第 三 种 方法 是 直接 读 取 表 的 数据 ， 将 数据 读 出 后 ， 根 据 emp_id 和 emp_name 两 个 条 件 进 行 过 滤 ， 
获得 所 需要 的 数据 。 

另外 ， 还 有 一 种 数据 访问 路 径 没 有 在 上 述 示例 中 出 现 ， 这 种 方法 是 从 Oracle 9i 开 始 引 入 的 。 
比如 , 我 们 有 一 个 复合 索引 IDX_ID_NAME, 这 个 索引 包含 两 个 字段 emp_id 和 emp_name， 而 有 
这 样 一 条 SQL: 

select emp id,sal from emp where emp_name= john' 

这 种 情况 下 , 我 们 可 以 通过 IDX_ID NAME 来 查找 所 需要 的 数据 。 由 于 emp name 不 是 这 个 
索引 的 第 一 个 字段 ,因此 无 法 像 普 通 的 索引 唯一 扫描 (index unique scan ) 或 索引 范围 扫描 (index 
range scan ) 那样 通过 一 次 定位 ， 然 后 顺 着 叶 节 点 链 进行 扫描 。 这 里 的 扫描 必须 是 跳跃 式 的 ， 
为 这 个 索引 的 前 导 字段 是 emp_id， 所 以 扫描 时 ， 对 于 每 个 emp_id， 都 需要 做 一 次 定位 ， 然 后 通 
过 叶 节 点 链 查找 到 所 有 符合 条 件 的 记录 。Oracle 给 这 种 扫描 方式 起 了 一 个 很 形象 的 名 字 叫 做 index 
skip scan， 我 们 称 之 为 索引 跳跃 式 扫 描 。 正 因为 如 此 ， 分 段 的 数量 对 于 扫描 的 成 本 影响 很 大 。 本 
例 中 emp id 是 主键 ， 在 这 种 情况 下 ， 使 用 索引 跳跃 式 扫描 的 成 本 实际 上 是 比较 高 的 ， 其 开销 甚 
至 高 于 索引 全 扫描 。 

我 们 刚才 又 引入 了 另外 一 种 索引 访问 的 方式 ， 即 索引 全 扫描 ， 它 包括 两 种 不 同 的 方式 : 一 种 
称 为 索引 全 扫描 (index full scan )， 另 外 一 种 称 为 索引 快速 全 扫描 (index fast full scan )。 为 什么 
要 使 用 索引 全 扫描 呢 ? 我 们 先 来 看 一 条 SQL: 

select emp_name from emp where emp_name is not null 


在 emp. name 上 有 一 个 索引 ， 其 中 包含 了 所 有 emp name 不 为 空 的 值 ， 因 此 在 这 种 情况 下 , 
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只 要 对 整个 索引 进行 一 次 扫描 就 可 以 完成 这 条 SQL 了， 不 需要 进行 全 表 扫 描 。 一 般 来 说 ， 对 于 
字段 较 多 的 表 ,， 索引 的 大 小 会 远 小 于 表 的 大 小 ,因此 全 索引 扫描 的 成 本 会 远 小 于 全 表 扫 描 。 本 全 
可 以 使 用 索引 快速 扫描 ,根据 该 索引 的 扩展 ， 以 多 块 读 的 方式 来 进行 。 因 此 在 这 类 操作 中 , 我们 
会 看 到 会 话 出 现 大 量 的 db file scattered read 等 待 。 但 如 果 经 常 出 现 db file scattered read 等 待 ， 是 
不 是 就 说 明 系 统 中 出 现 了 全 表 扫 描 呢 ? 其 实 这 种 说 法 并 不 准确 , 因为 索引 快速 全 扫描 也 会 以 多 块 
读 的 方式 来 进行 。 

如 果 我 们 对 刚才 那 条 SQL 进行 一 些小 的 修改 : 

select emp_name from emp where emp name is not null order by emp_name 

这 时 ，SQL 的 执行 路 径 可 能 会 有 所 改变 , 将 不 再 使 用 索引 快速 全 扫描 。 这 是 因为 索引 快速 全 
扫描 是 根据 扩展 的 顺序 进行 的 ， 并 不 是 按照 emp name 值 的 大 小 进行 的 ， 因 此 这 样 扫描 出 来 的 
emp name 数据 不 会 按照 emp name 排序 ， 如 果 要 排序 ， 必 须 在 索引 扫描 完成 后 再 进行 。 这 样 的 
执行 计划 可 能 不 如 索引 全 扫描 便捷 , 这 两 者 之 间 是 存在 区 别 的 。 索引 全 扫描 是 根据 叶 节 点 链 来 进 
ÍTR, 扫描 首先 从 根 开始 ， 接 下 来 找到 叶 节 点 链 上 的 第 一 个 数据 块 ， 然 后 沿 着 叶 节 点 链 进行 。 由 
于 叶 节 点 链 是 根据 索引 键 值 排 序 的 ,因此 扫描 出 来 的 数据 也 是 经 过 排序 的 , 数据 读 出 后 不 需要 再 
次 排序 。 使 用 这 种 扫描 方式 时 ， 首 先 要 找到 索引 的 根 ， 然 后 通过 枝 节 点 找到 第 一 个 叶 节 点 ， 最 后 
再 顺 着 叶 节 点 链 扫描 整个 索引 。 另 外 ,索引 全 扫描 的 VO 成 本 要 比索 引 快速 全 扫描 大 很 多 ， 尽 管 
读 取 根 节点 和 叶 节 点 的 成 本 并 不 大 ， 但 由 于 顺 着 叶 节 点 链 扫描 整个 索引 时 无 法 进行 多 块 读 操作 ， 
而 只 能 进行 单 块 读 操作 ， 因 此 会 产生 非常 大 的 VO 开销 。 在 这 种 索引 扫描 进行 时 ， 如 果 我 们 对 会 
话 进 行 跟踪 ， 会 发 现 大 量 的 db file sequential read 等 待 。 

在 这 里 , 大 家 可 能 会 有 一 个 疑问 , 带 order by 的 SQL 语 句 使 用 索引 全 扫描 的 成 本 是 否 一 定 小 
于 索引 快速 全 扫描 呢 ? 实际 上 , 这 不 能 一 概 而 论 , 关键 要 看 排序 操作 的 成 本 是 否 大 于 索引 单 块 扫 
描 与 索引 多 块 扫 描 之 间 的 IO 成 本 差 。 

谈 到 这 里 ,大 家 应 该 已 经 基本 了 解 了 索引 访问 的 主要 方式 。 实 际 上 , 还 有 一 种 索引 访问 的 操 
作 本 节 并 没有 讨论 ， 就 是 位 图 索引 的 访问 。 由 于 位 图 索引 的 结构 十 分 特殊 ， 没 有 枝 节 点 ， 而 是 一 
种 平面 结构 ， 因 此 ， 如 果 通 过 位 图 索引 进行 扫描 ， 就 只 有 一 种 扫描 方式 ， 这 种 方式 类 似 于 普通 索 
引 的 索引 快速 全 扫描 ,根据 该 索引 的 扩展 ,通过 多 块 读 进 行 扫描 ,这 是 因为 位 图 索引 的 每 个 数据 
块 中 都 可 能 包含 我 们 所 需要 的 键 值 。 


11.2.1 小 表 用 索引 有 意义 吗 


传统 观念 认为 ,小 表 使 用 索引 意义 不 大 ,全 表 扫 描 可 能 具有 更 高 的 效率 。 实 际 上 , 我 们 理解 
了 表 访 问 的 方式 ,就 可 以 来 分 析 这 个 问题 了 。 如 果 要 访问 一 张 没 有 索引 的 表 ， 我 们 需要 读 出 这 张 
表 的 所 有 数据 并 进行 比 对 ， 这 样 才能 得 到 查询 的 结果 。 由 于 每 次 读 取 表 数据 行 的 数量 是 有 限 的 ， 
此 访问 一 张 只 有 三 四 个 数据 块 的 小 表 可 能 就 需要 2 ~ 30 个 BUFFER GET. 

假如 我 们 从 一 张 有 350 条 记录 的 表 中 查找 一 条 记录 ， 如 果 这 张 表 的 数据 都 已 经 在 DB Cache 
中 了 ， 那 么 要 完成 全 表 扫 描 就 需要 产生 8 个 BUFFER GET: 
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| Id | Operation Name | Rows | Bytes | Cost (%CPU)| Ti me 
| 0 | SELECT STATEMENT | 1| 79 | 3 (0)| 00:00:01 | 
|* 1 | TABLE ACCESS FULL] T3 | 1 | 79 | 3 (0) | 00:00:01 | 


50 recursive calls 
0 db block gets 
8 consistent gets 
0 physical reads 
0 redo size 

484 bytes sent via SQL*Net to client 

396 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
1 rows processed 


而 如 果 我 们 使 用 索引 访问 这 张 小 表 , 通过 根 节 点 马上 就 可 以 找到 相关 的 叶 节 点 ,然后 定位 符 
合 条 件 的 记录 ,最 后 通过 ROWID 就 可 以 快速 定位 到 要 查找 的 那 条 记录 ,这 样 的 查询 开销 可 能 会 
小 于 全 表 扫 描 。 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time 

| 0 | SELECT STATEMENT | | | 79 | 2 (0)| 00:00:01 
| 1 | TABLE ACCESS BY INDEX ROWD| T3 | 1 | 79 | 2 (0)| 00:00:01 
|* 2 | INDEX RANGE SCAN [IDX T3]. 1 | | 1 (0)| 00:00:01 


redo size 
484 bytes sent via SQL*Net to client 
396 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
1 rows processed 


通过 上 面 的 测试 , 我 们 又 推翻 了 一 个 大 家 以 前 都 承认 的 “真理 ”。 不 使 用 索引 直接 访问 小 表 ， 
效率 未 必 是 最 高 的 ， 这 和 表 的 记录 大 小 、 记 录 分 布 有 很 大 的 关系 。 


11.22 ”位 图 索引 为 什么 不 适合 大 并 发 量 环境 


对 于 某 些 情况 来 说 , 普通 的 B 树 索引 是 无 能 为 力 的， 比如 全 国 所 有 人 的 身份 证 信息 表 , 共有 
约 13 亿 条 记录 ， 其 中 性 列 这 个 字段， 只 有 男 、 女 两 个 取 值 ， 对 于 该 字段 创建 B 树 索引 ， 访 问 效 
率 是 很 低 的 。 对 于 这 类 情况 ，Oracle 提供 。 位 图 索引 和 普通 的 B 
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树 索 引 有 所 不 同 , 它 没有 树 状 结构 ,而 只 有 一 个 类 似 HEAP 表 的 平面 结构 。 位 图 索引 虽然 也 有 校 


节点 


据 块 的 范围 , 枝 节 点 可 以 在 位 


点 , 但 它 和 B 树 索引 的 校 节 点 是 不 同 的 , 没有 排序 和 导航 功能 , 仅仅 指出 了 包含 某 个 键 值 的 数 
图 索引 值 扫 描 时 缩小 索引 扫描 的 范围 。 位 图 索引 的 访问 方式 包括 位 


图 索引 全 扫描 (bitmap index full scan )、 位 图 索引 值 (bitmap index single value )、 位 图 索引 快速 
全 扫描 (bitmap index fast full scan ) 等 。 下 面 通 过 一 个 实验 来 介绍 位 图 索引 的 结构 。 


首先 创建 一 张 表 ta， 捐 


create table ta (a 


insert into 
insert into 
insert into 
insert into 
insert into 
insert into 
insert into 
insert into 
insert into 
commi t; 


ta 
ta 
ta 
ta 
ta 
ta 
ta 
ta 
ta 


cha 
va 
va 
va 
va 
va 
va 
va 
va 
va 


r(1) 

ues ('1' 
ues ('2' 
ues ('3' 
ues ('4' 
ues ('4' 
ues ('4' 
ues ('2' 
ues ('1' 
ues ('3' 


create bitmap index bi ta on ta(a) 
接 下 来 ， 需 要 使 用 ALTER SYSTEM DUMP DATAFILE...BLOCK... 语 句 把 位 图 索引 的 叶 节 点 
内 容 转 储 出 来 : 


Leaf block dump 


header address 181916764=0xad7d45c 
kdxcol ev 
KDXCOLEV 
kdxcol ok 
kdxcoopc 
kdxconco 
kdxcosdc 
kdxconro 
kdxcof bo 
kdxcof eo 
kdxcoavs 
kdxl espl 
kdxl ende 
kdxl enxt 
kdxl eprv 
kdxledsz 0 

kdxlebksz 8032 


rows 


со 


0 
1; 
2 
3 . 


row#l 


со 
со 
со 


0 
1; 
2 


[80 


[79 


0 
Flags 
0 


0x80: opcode=0: iot flags-- 
4 


0 
4 
44z0x2 


C 


7947=0x1f0b 


1903 
0 

0 
0=0x0 
0=0x0 


11] flag: 


en 1; 
en 6; 
en 6; 
en 2; 


en 1; 
en 6; 
en 6; 


1): 
6 
6 
2) 
90] flag: 
1): 
6 
6): 


02 ad aa 00 00 
02 ad aa 00 07 
81 

-, lock: 0 


02 ad aa 00 00 
02 ad aa 00 07 


和 一些 数 据 ， 然 后 提交 ， 再 创建 一 个 位 图 索引 : 


is convertedzY 
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col 3; len 2; (2): 
row#2[7968] flag: 
col 0; len 1; (1): 
col 1; len 6; (6): 
col 2; len 6; (6): 
col 3; len 3; (3): 


row#3[7947] flag: 


col 0 en 1; (1): 
col 1; len 6; (6): 
col 2; len 6; (6): 
col 3; len 2; (2): 
E end of lea 

从 上 面 的 数据 我 们 


引 的 构成 。 


row#0[ 8011] flag: 


col 0; len 1; (1) 
col 1; len 6; (6) 
col 2; len 6; (6) 
col 3; len 2; (2) 


首先 可 以 看 出 , 位 


要 原因 。 由 于 索引 较 小 


再 来 看 索引 的 结构 


C8 42 


lock: 0 


03 02 ad aa 00 00 
03 02 ad aa 00 0f 
c9 04 01 
E , lock: 0 
03 02 ad aa 00 00 
03 02 ad aa 00 07 
: c8 38 
block dump 


可 以 看 出 , 这 里 记录 了 4 条 位 图 信息 。 下 面 通过 第 1 条 记录 来 分 析 位 图 索 


: 31 
: 03 02 ad aa 00 00 
: 03 02 ad aa 00 07 
: c8 81 


图 索引 没有 枝 节 点 ,直接 是 叶 节 点 。 这 也 是 位 图 索引 占用 空间 比较 小 的 主 


， 所 以 全 索引 扫描 的 效率 应 该 高 于 了 树 索引 。 
, 我 们 会 发 现 每 组 位 图 是 由 4 个 字段 组 成 的 。 第 1 个 字段 表示 键 值 ( “1 ); 


2 个 字段 是 位 图 所 表示 的 数据 块 的 RDBA RE; 第 3 个 字段 是 位 图 所 表示 的 数据 块 的 КОВА 


高 值 ; 第 4 个 字段 是 位 图 信息 ，C8 表示 位 图 是 8 位 长 的 ，0X81 可 展开 为 10000001， 由 于 位 图 的 


顺序 是 从 右 向 左 ， 因 此 第 1 条 记录 和 第 8 条 记录 的 键 值 都 是 “1’。 同 理 ,， 第 


247 (BEE ‘2’ ) 


的 位 图 信息 是 C8 42， 其 中 0X42 可 展开 为 01000010， 即 第 2 行 和 第 7 条 记录 的 键 值 是 “2 "。 


接 下 来 ， 我 们 再 搬入 几 条 记录 ， 来 观察 这 个 位 图 索引 的 变化 。 


insert into ta 
insert into ta 
insert into ta 
commit; 

以 下 是 插入 了 几 行 


Leaf block dump 


values ('3'); 
values ('3'); 
values ('2'); 
数据 后 位 图 索引 的 新 内 容 : 


header address 181916764=0xad7d45c 


kdxcolev 0 
KDXCOLEV 
kdxcolok 0 
kdxcoopc 0x80 
kdxconco 4 
kdxcosdc 0 
kdxconro 7 
kdxcofbo 50=0x32 
kdxcof eo 


kdxcoavs 7833 


opcode=0: 


Flags =- - - 


iot flags=--- is converted=Y 


7883=0xlecb 
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dM 


kdxlespl 0 
kdxl ende 2 
ках enxt 0=0x0 
kdxleprv 0=0x0 
kdxledsz 0 
kdxlebksz 8032 


row#0[8011] flag: 
1): 
6): 
6): 
2] 


col 0; Теп 1; 

col 1; Теп 6; 

col 2; len 6; 

col 3; len 2; 
row#1[7990] flag: 
col 0; len 1; 

col 1; len 6; 

col 2; len 6; 

col 3; len 2; 
row#2[7883] flag: 
col 0; len 1; 

col 1; len 6; 

col 2; len 6; 

col 3; len 1; 
row#3[7968] fla 
col 0; len 1; 

col 1; len 6; 

col 2; len 6; 

col 3; len 3; 


row#4[7925] flag: - 
1): 
6): 
6): 
3): 


col 0; len 1; 
col 1; len 6; 
col 2; len 6; 
col 3; len 3; 
row#5[7903] flag: 
col 0; len 1; 
col 1; len 6; 
col 2; len 6; 
col 3; len 3; 
row#6[7947] flag: 
col 0; len 1; 
col 1; len 6; 
col 2; len 6; 
col 3; len 2; 
E end of lea 


1): 
6): 


1): 


1): 
6): 
6): 


1): 
6): 
6): 
2 a 


2): 


CO C» CO» i= кэ AD 


3): 


03 02 ad aa 00 
03 02 ad aa 00 
c8 81 

E , lock: 2 


03 02 ad aa 00 
03 02 ad aa 00 
c8 42 

E , lock: 2 


03 02 ad aa 00 
03 02 ad aa 00 


D-, lock: 2 


03 02 ad aa 00 
03 02 ad aa 00 
c9 04 01 

-D-, lock: 2 


03 02 ad aa 00 
03 02 ad aa 00 
c9 04 03 

- , lock: 2 


03 02 ad aa 00 
03 02 ad aa 00 
c9 04 07 

E , lock: 0 


03 02 ad aa 00 
03 02 ad aa 00 
c8 38 

block dump ----- 


可 以 看 出 ， 行 数 变 成 了 7. 


引 的 行 发 生 了 裂变 和 重组 。 在 原 有 的 8 行 数据 上 增加 3 f 
看 来 数据 的 变化 对 位 图 索引 影响 很 大 。 


00 
07 


00 
07 


08 
0f 


00 
0f 


00 
Of 


00 
0f 


00 
07 


每 个 键 值 的 位 图 无 法 在 一 行 中 表示 ， 这 是 因为 数据 的 变化 导致 索 
， 就 导致 索引 发 生 如 此 大 的 变化 ， 


从 上 面 的 结果 可 以 看 出 ,在 表 数 据 发 生变 化 时 , 位 图 索引 也 会 发 生 大 面积 的 变化 , 因此 , 在 


DML 操作 时 , 锁定 记录 的 范围 是 一 组 记录 , 而 不 像 普 通 B 树 索 引 一 样 
这 就 会 影响 这 张 表 上 并 发 DML 操作 的 性 和 
化 也 会 很 严重 ， 索 引 访问 的 效率 会 有 较 明 显 的 下 降 。 


ЕВЕ. 另外 ， 经 常 进行 17 


只 影响 一 行 数据 ， 


DML 操作 的 表 ， 位 图 索引 的 碎片 
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从 上 述 两 个 原因 ， 我 们 可 以 得 出 结论 ， 位 图 索引 不 适合 在 DML 操作 十 分 频繁 、 并 发 量 较 大 


的 表 上 使 用 。 


从 位 图 索引 的 结构 特点 来 看 ,我 们 可 以 发 现 一 个 位 图 索引 的 优化 方法 。 如 果 某 张 表 相 对 静态 ， 
而 且 通 过 位 图 索引 访问 的 频率 很 高 , 那么 就 可 以 考虑 将 表 中 数据 按照 键 值 排序 组 织 , 这 样 位 图 索 
引 较 小 ， 访 问 效率 最 高 。 我 们 来 看 下 面 的 示例 : 


SQL> select ext 
where segment_n 
EXTENT_ID F 


со ы C» n — CO кә = c 


wo 


10 
11 rows selecte 


SQL> CREATE TAB 
Table created. 
SQL> CREATE BIT 
Index created. 
SQL> SELECT EXT 
WHERE SEGMENT_N 


EXTENT ID F 


ent_id,file_id, block_id, blocks from dba extents 
ame=' [DX TESTI' 
ILE ID BLOCK ID BLOCKS 


co 
co 
сә 
+ 
+ 
со со со со со со со со со со со 


d. 
LE TESTI 1 AS SELECT * FROM TESTI ORDER BY STATUS; 
MAP INDEX I DX TESTI 1 ON TEST1_1( STATUS) 


ENT ID, FILE ID, BLOCK ID , BLOCKS FROM DBA EXTENTS 
AMEz'IDX TESTI l' 


ILE ID BLOCK ID BLOCKS 
1 91296 8 
1 91304 8 
1 91312 8 
1 91320 8 


从 上 例 可 以 看 出 ， 如 果 表 数据 按照 位 图 索引 列 排序 ， 那 么 位 图 索引 就 会 比 一 般 情 况 小 很 多 ， 
这 个 索引 的 访问 开销 当然 也 就 很 小 。 相 对 比较 静态 的 数据 ,如 果 其 他 字段 的 范围 扫描 较 少 ,而 通 


过 位 图 索引 字段 的 访 | 
11.3 #385 
很 多 DBA TEM 3 


问 较 多 ， 就 可 以 考虑 通过 重组 表 数 据 来 提高 访问 性 能 。 


| 的 作用 
了 多 年 维护 工作 后 ， 依 然 不 知道 索引 是 需要 定期 维护 的 。 实 际 上 ， 索 引 比 


表 更 容易 产生 碎片 ， 这 是 因为 随 着 表 数 据 的 增加 、 删 除 和 修改 ， 索 引 在 不 停 地 重组 。 比 如 ， 如 果 
要 批量 删除 1 万 条 记录 ,在 删除 过 程 中 , 没有 提交 之 前 ， 这 些 索引 记录 是 不 能 被 重用 的 ， 此 时 如 
果 有 新 记录 搬入 , 那么 就 要 分 配 其 他 的 索引 记录 项 ,如 果 当 前 无 法 分 配 足够 的 记录 项 ， 就 只 能 分 
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裂 叶 市 点 ,以 获取 新 的 空间 。 这 样 的 情形 在 日 复 一 日 地 发 生 ， 因 此 索引 会 变 得 越 来 越 爱 肿 ， ЖО 


访问 的 效率 也 会 逐渐 下 降 。 受 影响 最 大 的 是 范围 扫描 ， 因 为 随 着 索引 碎片 的 增加 ,所 需 扫描 的 叶 


块 数量 也 会 有 所 增加 。 


老 白 曾 经 优化 过 一 个 银行 系统 ,系统 上 线 后 4 年 都 没有 做 过 索引 整理 ， 有 些 索引 已 经 比 表 都 


大 了 。 在 进行 了 一 次 索引 重建 后 , 第 2 天 平均 业务 端 到 端 响应 时 间 提 升 了 30% 多 , 这 可 是 很 多 优 
kM BRRR IRCEN, Æ 2011 年 底 老 白 参与 的 一 个 优化 项 目 中 ,数据库 并 不 大 ,但 所 有 表 
和 索引 的 扩展 总 容量 却 达 到 了 700 GB ， 经 过 索引 重建 后 ， 扩 展 减少 了 50 GB 多 的 空间 。 表 11-1 
是 老 白 最 近 一 个 优化 项 目 中 的 实际 案例 。 


表 11-1 
索 引 名 * 名 索引 大 小 X A Л ш H 
PK S LINE TG RELA ID S LINE TG RELA 2668 256 10 
LOC A RCVED PL FLOW R02 NO A RCVED PL FLOW 7710812 15142008 0.51 
IDX ARC A RCVBL PL FLOW ACCT Ч АВС A RCVBL PL FLOW 7088100 13452312 0.52 
LOC G TG PQ ORG NO G TG PQ 2842968 4562528 0.62 
IDX E CONSPRC SNAP PRC ID E CONSPRC SNAP 1713552 268968 6.37 
IDX TACTIC SP ID E CONSPRC TACTIC SNAP 1164536 223352 5.21 
LOC P MID RCVEDCOMP RCVSECT P MID RCVEDCOMP 1130192 1493840 0.75 
IDX A PC TRAN A PC TRAN 1096272 629980 1.74 
LOC В DATA, METER ID К DATA 1016320 612960 1.65 
LOC E CONS SNAP CONS CONS ID E CONS SNAP 614056 428072 1.43 
IDX R ENTITY MAINT APP NO R. ENTITY MAINT 344192 294912 1.16 
IDX JK, SYCJDL CONS NOORGNO JK SYCJDL 318976 266624 1.19 
PK S MP METER ВЕГА SCHM S MP METER ВЕГА SCHM 36864 4480 8.22 


可 以 看 到 ， 某 些 索引 的 段 大 小 甚至 超过 了 基 表 的 10 倍 。 在 这 种 情况 下 ， 对 索引 进行 重建 可 
以 达到 很 好 的 优化 效果 。 从 最 近 几 天 整理 的 一 些 索 引 来 看 ， 平 均 每 秒 的 事务 数 已 经 从 55 ЕЛ] 
了 96， 而 目前 仅仅 完成 了 一 部 分 表 的 索引 重建 。 
在 本 节 的 最 后 ， 老 白 将 献上 一 个 自己 编写 的 脚本 ， 用 于 分 析 表 和 索引 的 段 关系 ,并 找 出 可 能 
存在 的 碎片 化 较 严 重 的 索引 ， 如 代码 清单 11-1 所 示 。 


代码 清单 11-1 


col owner format al5 truncate 


col table name format a30 truncate 
col index name format a30 truncate 


select 

idx.owner owner 

idx.table name tablename 
idx.index name index name 
idx.blocks idx blocks 
tbl.blocks tbl blocks 


trunc(idx.blocks/tbl.blocks*100)/100 pct 
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from 
(select i.owner owner ,i.index name index name 
SUM(S1.blocks) blocks,i.table owner table owner 
i.table name table name 
from dba segments sl,dba indexes 
where 
sl.ownerzi.owner and sl.segment name-i.index name and 
i.owner not in 
('SYS', 'OUTLN', 'SYSTEM',' MGMT VIEW ,'SYSMAN',' DBSNMP',' WMSYS' , ' XDB' 
'"DIP',' GOLDENGATE', 'CTXSYS' ) 
GROUP BY i.owner ,i.index name ,i.table owner , i.table name ) idx 
(select t.owner owner ,t.table name table name, SUM(s2.blocks) blocks 
from dba segments s2,dba tables t 
where 
s2.0wnerzt.owner and s2.segment name-t.table name and 
t.owner 
not in 
('SYS', 'OUTLN', SYSTEM', ' МСМТ VIEW ,'SYSMAN','DBSNMP',' WMSYS' , ' XDB' 
'"DIP',' GOLDENGATE', 'CTXSYS' ) 
GROUP BY  T.OWNER, T. TABLE NAME 
) tbi 
where 
idx.table ownerztbl.owner and 
idx.table name-tbl.table name and 
(idx.blocks/tbl.blocks] >0. 5 and 
i dx. blocks»200 
order by 4; 


这 个 脚本 中 有 两 个 参数 : 一 个 是 二 者 比较 的 国 值 ， 这 里 老 白 使 用 了 0.5， 实 际 上 超过 0.1 就 
基本 都 是 需要 我 们 去 关注 的 ; 另外 一 个 是 索引 的 大 小 , 本 例 只 分 析 超 过 200 块 的 索引 ， 更 小 的 索 
引 不 在 考虑 范围 内 。 实 际 上 ， 这 个 脚本 找 出 的 索引 并 不 一 定 都 是 有 问题 的 , 由 于 有 些 索引 包含 了 
表 的 主要 字段 ， 因 此 超过 表 的 大 小 也 是 可 能 的 。 从 中 找 出 存在 疑问 的 索引 进行 分 析 ， 而 不 要 拘泥 
于 这 个 脚本 。 


在 线 重 建 索引 是 一 种 高 风险 的 操作 吗 


以 老 白 的 经 历来 说 ， 在 线 重建 索引 是 一 件 高 风险 的 事情 。 在 几 年 前 的 一 次 系统 割 接 工 作 中 ， 
有 一 个 操作 员 负 责 重建 索引 , 他 在 提交 了 一 个 脚本 后 ， 就 悠闲 地 坐 在 电脑 桌 前 喝 起 了 茶 。 有 人 从 
旁边 经 过 时 不 小 心 磁 了 他 一 下 ,水 酒 到 了 笔记 本 电脑 上 , 他 本 能 地 关闭 电脑 。 正 在 他 手忙脚乱 地 
处 理 自己 的 事情 时 ， 旁 边 的 业务 系统 突然 开始 出 现 大量 的 ORA-00600: internal error code, 
arguments: [kkdlfjou_1] 错 误 。 经 过 检查 发 现 ， 索 引 重 建 失败 导致 了 索引 损坏 。 此 时 重建 或 者 删除 
都 无 法 成 功 ， 重 建 这 个 索引 ， 系 统 就 会 出 现下 面 的 错误 : 


ORA-08104: this index object 50528 is being online built or rebuilt 


COMMAND: 
alter table prod04.idx acct list rebuild online; 


这 是 由 于 索引 重建 机 制造 成 的 ,在 线 重建 索引 是 基于 日 志 表 的 。 当 开始 在 线 重建 索引 时 ， 系 
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统 会 创建 一 个 临时 日 志 表 ， 这 张 表 被 用 于 存放 索引 重建 期 间 产 生 的 日 志 信息 。 同 时 在 IND$ 中 ， 
这 个 索引 的 FLAG 字段 上 会 被 设置 REBUILD 标识 (512)， 当 索引 信息 变更 时 ， 会 把 变更 信息 存 
入 日 志 表 。 而 在 线 重 建 如 果 失 败 了 ,这 个 日 志 表 和 数据 字典 中 的 状态 位 都 需要 靠 SMON 来 清理 。 
要 清理 这 个 日 志 表 , 需要 先 锁定 这 张 表 , 由 于 该 表 的 数据 一 直 在 变化 , SMON 无 法 对 其 进行 锁定 ， 
此 就 不 能 及 时 清理 。 如 果 索 引 所 在 的 表 变 更 十 分 频繁 , 那么 这 项 清理 工作 就 有 可 能 会 持续 几 天 
甚至 几 周 才能 完成 。 

鉴于 在 线 重建 索引 是 高 风险 的 操作 ， 因 此 老 白 建议 进行 该 操作 时 要 注意 以 下 几 点 : 
а 所 有 操作 都 写成 脚本 在 后 台 以 nohup 方式 运行 ; 
口 准备 好 应 急 预案 ， 一 旦 出 现 问题 ， 马 上 采取 措施 ; 
口 对 于 高 可 用 性 要 求 的 系统 ， 不 要 让 此 操作 在 无 人 值守 的 情况 下 进行 。 


11.4 索引 使 用 的 “三 大 纪律 八 项 注意 ” 


通过 前 面 几 节 的 讨论 , 大 家 应 该 已 经 明白 了 索引 的 基本 原理 , 也 了 解 到 了 索引 设计 的 一 些 基 
本 要 素 。 如 果 我 们 能 根据 每 个 SQL 的 特点 来 设计 相应 的 索引 ， 那么 所 有 的 SQL 都 可 以 通过 最 为 
适当 的 索引 去 访问 数据 ， 从 而 达到 最 佳 的 效果 。 不 过 这 种 设想 往往 是 很 难 实现 的 ， 因 为 这 样 需 要 
为 每 张 表 都 设计 数量 庞大 的 索引 , 系统 维护 索引 的 成 本 就 会 变 得 十 分 高 昂 。 那 么 我 们 应 该 如 何 来 
设计 索引 呢 ? 

俗话 说 “ 花 无 百 日 红 ”， 我 们 无 法 总 是 获得 最 佳 的 效果 。 因 此 在 处 理 问题 时 ， 应 该 重点 解决 
主要 矛盾 ， 索 引 设计 也 是 如 此 。 在 设计 时 ， 我 们 必须 为 执行 最 为 频繁 、 对 系统 性 能 影响 较 大 的 
SQL 设计 成 本 开销 最 小 的 索引 ， 而 一 些 次 要 的 SQL， 可 以 和 其 他 SQL 共用 索引 ， 这 些 索 引 可 能 
并 不 是 最 优 的 , 不 过 也 能 够 满足 目前 应 用 的 需求 。 而 那些 不 是 很 常见 的 SQL, 其 重要 程度 并 不 高 ， 
因此 是 否 为 它们 设计 索引 ， 就 应 该 视 具体 情况 而 定 了 。 老 白 总 结 了 一 些 索引 设计 方面 的 经 验 ,， 并 
将 它们 归纳 为 “三 大 纪律 八 项 注意 ”， 在 这 里 和 大 家 一 起 分 享 。 


三 大 纪律 


第 一 , 一 切 服 从 应 用 需要 。 在 一 张 表 上 创建 多 少 索 引 , 创建 什么 样 的 索引 , 并 无 一 定之 规 。 
不 能 说 一 张 表 上 有 了 7 个 索引 ， 就 不 能 再 创建 第 8 个 索引 了 。 设 计 索 引 时 ， 应 该 从 应 用 的 角度 
出 发 ， 不 可 轻易 相信 某 些 专家 ， 只 有 应 用 开发 者 才 对 自己 的 应 用 最 了 解 ， 请 一 个 不 了 解 具体 情 
况 的 专家 来 设计 索引 并 不 一 定 合适 ,除非 专家 能 够 认真 分 析 你 的 应 用 ,不 过 这 样 的 代价 就 相当 
高 了 。 

第 二 ， 除 非 有 很 大 的 把 握 ， 否 则 不 要 轻易 删除 索引 。 在 一 套 运 行 了 很 长 时 间 的 生产 系统 上 ， 
不 经 过 严格 论证 就 随意 删除 索引 ， 可 能 会 导致 严重 的 后 果 。 我 在 10 年 前 曾 磁 到 过 一 个 案例 ， 那 
一 次 在 给 客户 做 巡 检 时 我 发 现 了 大 量 无 用 的 索引 , 通过 MONITOR 工具 观察 了 一 个 星期 后 , R 
我 将 那些 没有 使 用 过 的 索引 全 部 删除 了 ， 清 理 共 2000 多 个 。 清 理 完成 后 某 些 应 用 的 性 能 确实 有 
所 提高 ， 而 且 系统 也 一 直 没 有 出 现 问题 。 但 过 了 几 个 月 ,元 旦 那天 , 我 接 到 了 那个 DBA 的 电话 ， 
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他 壬 笑 不 得 地 对 我 说 :;“ 老 白 ， 你 把 我 害 惨 了 ， 每 年 元 旦 早上 我 们 老板 都 要 看 一 个 重要 的 数据 ， 
这 回 没 出 来 ， 经 过 检查 ， 少 了 个 索引 ， 就 是 你 上 回 删 除 的 。” 从 那 以 后 ,我 再 也 不 敢 轻 易 动 手 清 
理 索 引 了 。 

第 三 ， 要 确保 表 和 索引 统计 数据 的 一 致 性 。 如 果 表 和 索引 的 统计 数据 不 匹配 ， 出 现 执行 计划 
错误 的 可 能 性 就 很 大 。 如 果 相 关 的 表 和 核心 业务 有 关 , 那么 将 会 造成 严重 的 性 能 问题 。 前 些 天 老 
白 就 碰 到 过 一 个 这 样 的 案例 ,在 给 一 个 客户 做 优化 项 目 时 ,由 于 是 在 数据 采集 阶段 ,所 以 每 天 早 
上 我 都 会 打开 topas 工具 观察 系统 的 资源 使 用 情况 。 有 一 天 我 发 现 CPU 的 IDLE ЛЛ О Т, Ж 
后 通过 vmstat 监控 发 现 r 队列 达到 了 50 左右， 而 这 个 指标 平时 只 有 20 多。 经 过 检查 ， 我 注意 到 
有 两 条 INSERT ... SELECT 语句 占用 了 近 20% 的 CPU 资源 。 通 过 一 个 上 午 的 分 析 ， 我 发 现 这 是 
由 于 统计 数据 的 问题 导致 走 错 了 索引 。 于 是 ,我 检查 了 表 的 LAST_ANALYZED 字段 ,发 现 是 2011 
年 12 月 做 的 分 析 。 难 道 是 统计 数据 过 旧 导 致 了 问题 ? 这 似乎 也 解释 不 通 ， 因 为 之 前 一 直 是 很 正 
常 的 。 后 来 我 和 客户 的 DBA 进行 了 沟通 ， 终 于 找 出 了 问题 的 原因 。 原 用 户 重 建 了 一 个 索引 ， 同 
时 对 索引 做 了 分 析 ， 从 而 使 索引 和 表 的 分 析 数 据 出 现 了 不 一 致 ， 进而 导致 了 这 个 问题 。 在 我 们 对 
这 张 表 重新 进行 了 分 析 后 ， 这 个 问题 就 解决 了 。 


八 项 注意 


第 一 项 : 索引 必须 是 有 用 的 。 不 使 用 的 索引 不 但 会 额外 增加 DML 操作 的 成 本 ， 而 且 可 能 
致 执行 计划 出 现 错误 。 因 此 必须 从 系统 中 清除 这 类 索引 。 清除 工作 最 好 在 系统 上 线 前 或 者 上 线 初 
期 完成 。 在 系统 运行 了 很 长 时 间 后 ， 即 使 监控 到 某 个 索引 没有 使 用 ， 也 不 能 轻易 地 清除 它 。 

第 二 项 : 尽 可 能 让 一 个 索引 为 更 多 的 SQL 服务 ， 设 计 合 理 的 复合 索引 是 十 分 关键 的 。 复 合 
索引 可 以 为 单个 过 滤 条 件 服务 , 也 可 以 为 组 合 过 滤 条 件 服务 。 我 们 无 法 为 每 种 WHERE 组 合 都 设 
计 独 立 的 索引 ， 因 此 统筹 索引 设计 的 关键 是 复合 索引 。 索 引 设计 者 一 定 要 把 握 好 这 一 点 。 

第 三 项 : 尽 可 能 将 复合 索引 中 选择 性 强 的 字段 放 在 前 面 , 这 样 可 以 减少 索引 范围 扫描 的 成 本 。 
但 在 有 些 情况 下 ， 我 们 需要 多 些 其 酮 。 比 如 ，ID 和 CREATE TIME 这 两 个 字段 ， 一 个 是 主键 ， 
一 个 是 创建 时 间 ， 按 照 一 般 的 情况 ,创建 复合 索引 时 ， 需 要 将 ID 放 在 前 面 ， 不 过 如 果 以 
CREATE TIME 为 查询 条 件 的 SQL 比较 多 , 而 ID 的 使 用 较 少 , 那么 我 们 在 设计 这 个 复合 索引 时 ， 
就 要 将 CREATE_TIME 放 在 前 面 。 

第 四 项 : 在 索引 设计 时 要 统筹 考虑 。 比 如 , 一 张 表 上 的 访问 过 滤 条 件 包括 PRODUCT_TYPE + 
PRODUCT_CLASSES 和 PRODUCT_TYPE + UPDATE, TIME 两 种 组 合 方式 , 我 们 可 以 创建 两 个 索 
3|, 也 可 以 考虑 创建 PRODUCT_TYPE + PRODUCT. CLASSES + CREATE, TIME 的 复合 索引 来 替 
代 两 个 索引 的 方案 。 

第 五 项 : 一 定 要 根据 实际 情况 选择 适当 的 索引 类 别 。 位 图 索引 和 B 树 索引 的 使 用 场合 是 不 同 
的 ,位 图 索引 存储 的 是 字段 值 的 位 图 ,因此 修改 某 个 索引 字段 的 值 时 ， 系 统 维护 索引 的 方式 也 和 
В 树 索 引 不 同 ,维护 时 可 能 会 同时 锁定 多 条 记录 。 基 于 位 图 索引 的 这 一 特点 ,在 某 张 表 针 对 索引 
字段 的 UPDATE 操作 或 者 某 张 表 的 INSERT/DELETE 操作 比较 频繁 的 情况 下 ， 是 不 适合 使 用 位 
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图 索引 的 ， 否 则 很 容易 出 现 死 锁 。 但 也 不 要 对 位 图 索引 存在 偏见 ， 有 些 DBA 认为 位 图 索引 不 适 
ВТЕ OLTP 系统 中 使 用 ， 这 也 是 错误 的 观点 。 只 要 使 用 得 当 , 不 出 现 死 锁 增 加 或 者 锁 冲 突 增 加 的 
现象 ， 在 OLTP 系统 中 使 用 位 图 索引 也 是 可 行 的 。 

第 六 项 : 要 注意 函数 索引 的 使 用 。 绝 大 多 数 开 发 人 员 对 函数 索引 了 解 不 多 ， 也 很 少 在 系统 
中 使 用 ， 有 些 DBA 还 会 故意 夸大 函数 索引 的 维护 开销 。 实 际 上 ， 函 数 索 引 也 是 一 种 B 树 索引 ， 
不 同 的 只 是 索引 的 键 值 是 通过 函数 计算 出 来 的 。 做 过 开发 的 人 都 很 清楚 ， 在 表 的 字段 上 使 用 函 
数 或 者 表达 式 是 很 难 避 免 的 ， 在 某 些 情况 下 ， 去 除 表 字 段 上 的 函数 代价 相当 高 。 这 时 ， 函 数 索 
引 就 是 最 佳 的 选择 。 事 实 上， 函数 索引 的 维护 成 本 并 没有 我 们 想象 的 那么 高 ， 和 善 通 索 引 相 比 ， 
函数 索引 的 维护 开销 增加 的 部 分 就 是 函数 计算 的 部 分 ， 在 大 多 数 情况 下 ， 这 些 成 本 都 是 可 以 承 
受 的 。 

第 七 项 : 尽 可 能 合并 类 似 的 索引 。 在 一 个 大 型 系统 中 ， 由 于 表 的 查询 条 件 在 不 断 地 变化 ,我 
们 很 可 能 会 创建 很 多 类 似 的 索引 。 老 白 在 以 往 的 工作 中 就 经 常会 磁 到 这 样 的 情况 , 一 套 系统 中 存 
在 A+B+C 和 A+C+B 两 个 类 似 的 索引 ,或 者 存在 A+C+E 和 A+B+E 这 样 的 索引 。 实 际 上 ， 这 样 
的 索引 设计 是 很 不 好 的 ， 不 仅 增加 了 额外 的 开销 ， 更 大 的 危害 是 很 容易 引起 SQL 执行 计划 的 不 
稳定 ， 因 此 对 这 些 索引 进行 适当 的 合并 整理 是 十 分 必要 的 。 

第 八 项 : 有 时 候 在 索引 中 增加 部 分 额外 字段 可 以 起 到 很 好 的 作用 。 对 于 一 些 查询 量 很 大 的 大 
表 ， 如 果 存 在 一 条 SQL: 

SELECT A FROM TAB1 WHERE В=:1 AND C=:2 

针对 上 述 情况 ，DBA 一 般 会 创建 一 个 B+C 的 索引 ， 但 实际 上 ， 如 果 创 建 一 个 B+C+A 的 索 
引 ， 就 可 以 避免 对 表 的 扫描 ， 通 过 索引 扫描 就 可 以 获得 所 需要 的 全 部 数据 。 

最 后 要 提醒 大 家 的 是 , 索引 是 需要 维护 的 ， 并 不 是 创建 后 就 万 事 大 吉 了 。 定 期 对 索引 进行 评 
估 和 维护 是 十 分 必要 的 ， 通 过 定期 检查 ОВА INDEXES 中 相关 统计 数据 的 变化 ， 我 们 可 以 粗略 
地 了 解 索 引 的 变化 。 比 如 索引 的 大 小 、B-LEVEL、CLUSTER FACTOR 等 ， 这 些 都 应 该 是 我 们 关 
心 的 数据 ,在 索引 刚 被 创建 或 者 重建 的 时 候 , 应 该 保存 这 些 数据 ， 并 定期 检查 一 些 关 键 索引 的 统 
计 信 息 。 如 果 发 现 这 些 数值 变化 较 大 ,就 需要 对 索引 进行 相关 的 维护 ,否则 索引 访问 的 效率 会 大 
幅度 降低 。 


11.5 案例 一 一 索引 危机 


本 节 介 绍 一 个 索引 优化 的 案例 , 通过 这 个 案例 , 读者 可 以 学 习 到 如 何 分 析 、 设 计 索 引 。 另 外 ， 
这 个 案例 也 介绍 了 一 种 非常 规 的 索引 优化 方法 ， 实 际 上 在 很 多 场合 都 可 以 使 用 此 方法 。 


4 月 1 日 无 法 修改 应 用 的 项 目 


刚才 在 会 议 室 和 郭 工 一 起 讨论 了 这 个 项 目 ， 最 近 一 两 个 月 ， 郭 工 他 们 这 套 系 统 的 CPU 使 用 
率 增加 了 20% 左 右 ， 而 白天 业务 高 峰 时 ， 基 本 上 都 在 90% ~ 100%, IDLE 基本 上 都 是 0。 郭 工 感 


11.5 ”案例 一 一 索引 危机 297 


觉 到 系统 的 风险 很 大 ， 于 是 向 领导 做 了 汇报 ， 李 总 就 急忙 叫 我 过 来 帮 他 们 分 析 分 析 。 

听 郭 工 介绍 ， 这 套 系统 2 周 后 将 迎 来 每 个 月 最 繁忙 的 时 段 ， 从 目前 的 情况 来 看 ， 这 个 12 个 
CPU 组 成 的 24 核 的 系统 ,，r 队列 已 经 达到 了 40 多 ， 如 果 不 做 一 些 优 化 ， 可 能 很 难 安全 度 过 几 天 
后 的 业务 高 峰 。 想 要 大 幅度 降低 CPU 的 使 用 率 ， 最 好 的 办 法 就 是 优化 应 用 。 

TE, 郭 工 把 开发 商 负责 维护 系统 的 组 长 也 叫 到 了 会 议 室 ,商讨 修改 应 用 的 事情 。 开 发 商 一 
听 要 修改 SQL， 头 马上 摇 得 跟 拨 浪 鼓 似 的 。 在 两 周 时 间 内 完成 SQL 修改 工作 ,对 于 开发 商 来 说 ， 
确实 难度 不 小 。 经 过 协商 ， 开 发 商 认为 索引 的 修改 和 PL/SQL 存储 过 程 的 优化 他 们 能 够 马上 配合 
我 们 进行 , 但 修改 程序 的 变更 , 他们 必须 上 报 给 公司 ， 走 公司 的 变更 流程 ,在 两 周 内 完成 这 项 工 
作 基 本 是 不 可 能 的 。 看 样子 开发 商 是 指望 不 上 了 ， 于 是 我 决定 把 优化 的 重点 放 在 索引 的 调整 上 。 
如 果 能 优化 几 个 BUFFER GET 较 大 的 SQL, 让 CPU 使 用 率 下 降 10% ~ 15%， 基 本 就 能 够 完成 任 
务 了 。 

我 采集 了 一 下 10 点 到 11 点 的 STATSPACK 报告 : 


Cache Sizes (end) 


Buffer Cache: 8,000M Std Block Size: 8K 
Shared Pool Size: 3, 200M Log Buffer: 10,240K 
Load Profile 
AA Per Second Per Transaction 
Redo size: 2,596,262.30 60,116.45 
Logical reads: 512,843.36 13,264.19 
Block changes: 22,523.53 521.53 
Physical reads: 2,637.11 61.06 
Physical writes: 672.75 15.58 
User calls: 21,920.49 507.57 
Parses: 6,339.75 146. 80 
Hard parses: 310.56 1.19 
Sorts: 1,714.43 39.70 
Logons: 0.44 0.01 
Executes: 6,434.11 148.98 
Transactions: 43.19 
% Blocks changed per Read: 3.93 Recursive Call %: 9.04 
Rollback per transaction %: 4.01 Rows per Sort: 48.64 


Instance Efficiency Percentages (Target 100%) 


Buffer Nowait % 99.98 Redo NoWait %: 99.99 
Buffer Hit %: 99.60 In-memory Sort %: 100.00 
Library Hit 9: 97.61 Soft Parse %: 95.10 
Execute to Parse %: 1.47 Latch Hit % 99. 36 


Parse CPU to Parse Elapsd %: 62.06 % Non- Parse CPU: 90. 83 
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Shared Pool Statistics Begin End 


Memory Usage % 100.00 100.00 
% SQL with executions»l: 30.49 31.15 
% Memory for SQL wlexec>1: 34.11 34.20 


Top 5 Timed Events 


e m % Total 
Event Waits Time (s) Ela Ti me 
db file sequential read 5,023,080 15,306 41.99 
CPU ti me 14,925 41.11 
global cache cr request 4,851,421 6,662 3.71 
db file scattered read 181,344 3,582 2.00 
latch free 4,553,880 3,512 1.99 


从 报告 上 看 ，CPU time 在 所 有 的 事件 中 排 在 第 二 位 ， 基 本 上 和 db file sequential read 事件 差 
不 多 。 另 外 , Non-Parse CPU 只 有 90% 左 右 ， 说 明 解析 消耗 的 CPU 也 不 少 。 但 由 于 只 有 两 三 天 的 
时 间 ， 这 部 分 优化 工作 就 暂时 不 考虑 了 。 从 等 待 事件 上 看 : 


Avg 
Total Wait Wait Waits 
Event Waits Ti meouts Ti me (5) (ms) /txn 
db file sequential read 5,023,080 0 15,306 15 32.3 
global cache cr request 4,851,421 4,394 6,662 1 ; 
db file scattered read 181,344 0 3,582 20 1.2 


VO 性 能 不 算 太 好 ， 不 过 也 还 算 凑 合 ， 不 会 有 太 大 的 性 能 影响 。 这 次 优化 重点 放 在 索引 调整 
上 ， 因 此 需要 考虑 的 其 他 方面 的 问题 较 少 ， 只 要 确保 索引 调整 后 ，TOP SQL 的 执行 计划 不 会 变 
坏 就 行 了 。 基 于 这 样 的 考虑 ， 整 个 优化 工作 就 变 得 很 简单 了 。 首先 挑 出 需要 优化 的 SQL, 然后 分 
析 是 否 可 以 通过 调整 索引 进行 优化 , 如 果 可 以 , 就 做 出 一 个 索引 调整 方案 , 由 开发 商 来 实施 即 可 。 
一 些 较 小 的 索引 调整 可 以 立即 进行 ， 但 如 果 索 引 的 大 小 超过 200 MB, ， 就 需要 在 中 午 或 者 晚上 业 
务 较 少 的 时 间 进 行 。 

我 在 STATSPACK 报告 中 查找 了 逻辑 读 较 大 的 SQL， 排 在 第 一 位 的 是 一 条 一 小 时 执行 了 50 
万 次 的 SQL， 每 次 开销 为 1000 多 个 BUFFER GET。 在 查看 了 执行 计划 后 ， 我 发 现 它 通过 一 个 索 
引 做 范围 扫描 ,看 样子 也 没有 多 大 的 问题 ,只 是 执行 频率 较 高 而 已 。 排 在 第 二 位 的 是 一 条 很 简单 
的 SQL: 

SELECT ORDER ID , 


NVL(PAYMENT 1D, -1) PAYMENT 10, 

ACCT 1D, 

SERV ID, 

ACTI ON, 

STATE , 

TO CHAR(CREATED DATE, ' YYYYMMDDHH24MI SS' ) 

TO CHAR(STATE РАТЕ, ' ҮҮҮҮММОРНН24МІ SS') FROM A XXX 

WHERE NVL(PAYMENT |D,-1)»-:lPayment|D АМО STATE=:sState ORDER BY 
NVL(PAYMENT 10, -1), CREATED DATE 
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这 条 SQL 每 次 访问 的 BUFFER GET 只 有 不 到 2500 个 ， 不 过 访问 的 次 数 不 少 ， 有 五 六 万 次 。 
实际 上 , 这 条 SQL 的 写法 是 有 问题 的 , PAYMENT. ID 字段 上 是 有 索引 的 , 不 过 由 于 使 用 了 NVL 
函数 ， 导 致 这 个 索引 无 法 使 用 。 其 实 PAYMENT. ID 肯定 是 一 个 大 于 0 的 字段 ， 由 于 在 该 字段 上 
有 一 个 “>” 过 滤 条 件 ， 因 此 满足 该 条 件 的 记录 PAYMENT. ID 肯定 不 为 室 ， 所 以 如 果 把 NVL PR 
数 去 掉 ， 改 为 : 


SELECT ORDER ID 
NVL(PAYMENT 10, -1) PAYMENT 10 
ACCT 1D, 
SERV ID, 
ACTI ON, 
STATE , 
TO CHAR(CREATED DATE, ' YYYYMMDDHH24MI SS' ) 
TO CHAR(STATE РАТЕ, ' ҮҮҮҮММОРНН24МІ SS') FROM A XXX 
WHERE PAYMENT lD»s:lPaymentiD АМО STATE=:sState ORDER BY 
PAYMENT 10, CREATED DATE 


从 语义 上 来 看 ,这 两 条 SQL 是 完全 等 价 的 。 由 于 PAYMENT ID 字段 是 十 分 常用 的 ， 因 此 必 
须 保 留 PAYMENT ID 上 的 索引 , 所 以 优化 这 条 SQL 的 最 佳 方案 是 修改 程序 , 去 除 PAYMENT. ID 
上 的 NVL 函数 。 在 和 开发 商 沟通 后 , 他们 也 认为 这 是 开发 人 员 的 一 个 失误 , 这 个 NVL 函数 是 可 
以 去 掉 的 ,不 过 修改 程序 的 审批 和 测试 流程 十 分 繁琐 ,短期 内 很 难 实施 ,最 好 能 使 用 其 他 解决 方 
案 。 如 果 要 找 其 他 解决 方案 ， 就 只 能 考虑 在 NVL(PAYMENT ID,-D) 上 创建 函数 索引 了 。 根 据 开 
发 人 员 的 介绍 ， 这 个 SQL 是 查询 PAYMENT ID 大 于 某 个 值 的 未 处 理 过 的 记录 的 数量 ，STATE 
的 值 只 有 五 六 个 ,选择 性 一 般 , 开 发 人 员 帮 我 找到 一 个 PAYMENT ID ,我 通过 SELECT COUNT(*) 
FROM A. XXX WHERE PAYMENT_ID>:PID 语句 查询 了 一 下 , 满足 大 于 PAYMENT ID 的 记录 大 
约 占 整 个 表 的 15。 于 是 我 又 加 上 STATE 的 过 滤 条 件 查 询 了 一 次 ， 查 出 的 记录 总 数 占 整个 表 的 
1/60。 在 这 种 情况 下 ,创建 NVL(PAYMENT_ID)+STATE 的 索引 ， 效 果 比 创建 PAYMENT ID 的 
单列 索引 要 好 得 多 。A_XXX 表 的 总 记录 数 为 200 多 万 条 ， 因 此 在 业务 空闲 期 创建 索引 对 系统 影 
响 不 大 。 于 是 ,我 建议 中 午 就 在 这 张 表 上 创建 这 个 索引 。 

中 午时 , 开发 商 创建 了 这 个 复合 索引 。 我 午饭 后 回 到 办 公 室 是 下 午 1:30, 查看 了 系统 的 负载 
情况 ，CPU 使 用 率 只 有 50% 左 右 。 我 知道 这 肯定 不 是 刚才 那个 索引 的 功劳 ， 可 能 是 中 午 很 多 营 
业 厅 都 没什么 业务 的 缘故 。 我 做 了 一 次 收集 级 别 为 6 的 STATSPACK 分 析 , 从 生成 的 STATSPACK 
报告 中 可 以 看 出 ， 这 条 SQL 在 半 小 时 里 执行 了 不 到 两 万 次 ,平均 每 次 执行 的 BUFFER GET 的 数 
HE 1500 左右 ， 比 刚才 有 了 明显 的 下 降 ， 应 该 是 执行 计划 发 生 了 改变 。 为 了 确认 这 一 点 ， 我 又 
使 用 SPREPSQL 生成 了 这 条 SQL 的 报告 ,在 SQL 报告 中 ， 我 明确 地 看 到 SQL 执行 时 使 用 了 新 
建 的 索引 。 

F 3 点 到 5 点 是 业务 高 峰 期 ， 在 2 点 半 之 后 ， 系 统 负载 就 在 不 断 地 上 升 ， 不 过 CPU 使 用 
率 一 直 徘徊 在 80% 左 右 。 我 心中 难免 有 些 喜悦 ， 难 道 刚才 那个 索引 居然 取得 了 这 么 好 的 效果 ? 

3 点 10 分 左右 ，CPU 使 用 率 再 次 突破 了 90%， 几 分 钟 后 ， 达 到 了 95%， 到 3 点 30 分 左右 ， 
IDLE 终于 消失 了 。 虽 然 我 有 点 失望 ， 不 过 这 也 在 预料 之 中 ， 想 通过 一 两 个 索引 就 达到 优化 的 目 
的 ， 是 不 太 现实 的 。 在 这 套 系 统 中 ， 我 还 有 很 多 的 工作 要 做 。 
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4 月 2 日 索引 范围 扫描 的 优化 方法 


昨天 下 午 又 优化 了 几 个 SQL， 优 化 后 都 有 了 明显 的 性 能 提升 ， 不 过 从 今天 上 午 10 点 多 观察 
到 的 CPU 使 用 率 来 看 ， 好 像 变化 不 大 。 由 于 排队 效应 的 存在 ， 简 单 的 减法 并 不 能 完全 解决 问题 。 
解决 了 以 前 排 在 前 面 的 几 个 SQL 的 问题 后 ， 又 出 现 了 一 些 新 的 SQL， 其 中 一 条 SQL 每 次 执行 的 
BUFFER GET 数量 高 达 3 万 多 : 


select a.filename, b.source id, b.source path, b.localnet abbr 
b.file fmt,b.is txt fmt, a.deal flag 
from SCH XXX a, BBB b 
where (a.deal flagz' W or a.deal flagz' B') and 
a.validflagz'Y' and b. pipe_id=:szPipeld and a.source id-b.source id 


有 具体 的 执行 计划 如 下 : 


| Operation | PHV/ Object Name | Rows | Bytes| Cost 

| SELECT STATEMENT | 1104374539 ----| | | 3486 | 
| HASH JOIN | | 79K| 7M| 3486 | 
| TABLE ACCESS BY |NDEX ROWID | BBBBB | 2 | 98| 2 | 
| INDEX RANGE SCAN [ЕК SOURCE WORKFLOW | | 1 | 
| TABLE ACCESS FULL | SCH_XXXXX | 1M| — 61M| 3474 | 


从 这 个 执行 计划 来 看 ， 对 SCH_XXXX 的 扫描 是 开销 最 大 的 ， 这 张 表 中 扫描 的 记录 数 为 100 
万 (1M )。 通 过 SPREPSQL 报告 ， 我 们 看 到 ; 


Statement Total Per Execute 

Buffer Gets: 626,984 39,186.5 

Disk Reads: 425,693 26,605.8 

Rows processed: 46 2:0 

CPU Ti me(s/ ms): 50 3,113.1 

Elapsed Ti me(s/ ms): 988 61, 779.7 

Sorts: 0 .0 

Parse Calls: 16 1.0 
Invalidations: 0 
Version count: 2 
Sharable Mem(K): 29 
Executions: 16 


平均 每 次 执行 返回 的 记录 数 是 2.9 条 ， 也 就 是 说 真正 符合 条 件 的 记录 只 有 区 区 3 条 左右 。 这 
和 执行 计划 中 的 79K 相差 其 远 , 于 是 我 检查 了 这 张 表 , 这 张 表 总 计 有 200 万 条 记录 。 在 这 张 表 上 ， 
存在 两 个 过 滤 条 件 (a.deal_flag="W' or a.deal flag='B') 和 a.validflag="Y'。 我 首先 分 析 了 一 下 
validflag : 


Select validflag,count(*) from sch xxxx group by validflag; 
发 现 表 中 的 大 多 数 记 录 都 是 validflag='Y' 的 记录 ， 这 个 字段 的 选择 性 是 很 差 的 ， 接 着 ， 我 又 
检查 了 deal_flag， 发 现 绝 大 多 数 记 录 都 是 deal_flag='Y' 的 ， 其 他 的 记录 非常 少 ， 有 时 甚至 是 0。 
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这 是 一 个 典型 的 字段 倾斜 案例 , 凑巧 的 是 , 在 这 个 SQL 中 并 没有 使 用 绑 定 变量 , 因此 在 deal. flag 
上 创建 一 个 索引 ， 并 且 分 析 一 下 柱状 图 就 可 以 解决 问题 。 经 过 和 客户 的 协商 ， 由 于 这 张 表 只 有 
200 万 条 记录 ， 因 此 我 们 决定 立即 创建 索引 ， 并 做 表 分 析 ， 于 是 我 马上 执行 了 下 面 的 脚本 : 


CREATE INDEX SHCJ.IDX DEALFLAG ON SHCJ.SCH XXXX( DEAL FLAG) ; 

Exec DBMS STATS.GATHER TABLE STATS(ownnamez» 'SHCJ', tabname=> 'SCH XXXX', 
esti mate percentz»30, method opt=>'for all indexed columns size 
skewonly',cascade=>true, degree=>2); 


索引 创建 后 ,我 再 次 分 析 了 表 和 索引 ， 发 现 表 对 索引 字段 中 的 倾斜 字段 分 析 了 柱状 图 。 这 里 
可 以 将 Method. opt 设置 为 for all columns size auto', XÆ 10g 版 本 的 默认 值 ， 而 9i 版 本 的 默认 值 
是 for all columns size 1 ， 也 就 是 不 分 析 柱 状 图 。 

上 述 操作 完成 后 ， 我 马上 对 这 个 SQL 进行 了 分 析 ， 发 现 BUFFER GET 的 数量 从 近 4 万 减少 
到 了 10.7， 这 个 SQL 产生 的 物理 读 基本 也 没有 了 。 这 说 明 索 引起 到 了 很 好 的 作用 。 

从 上 午 业 务 高 峰 期 的 情况 来 看 , 虽然 我 又 调整 了 三 四 个 SQL, 不 过 总 体 的 效果 并 没有 很 明显 
的 提升 。 在 上 午 10 点 到 11 点 30 分 之 间 , 系统 的 CPU 使 用 率 仍然 处 于 95% ~ 100% 的 高 位 , 虽然 
平均 事务 响应 时 间 有 了 20% 左 右 的 提升 ， 但 还 是 很 难 彻底 解决 问题 。 在 STATSPACK 报告 中 ， 
已 经 找 不 到 明显 的 可 以 通过 索引 调整 进行 优化 的 SQL 了 ， 如 何 解决 CPU 负荷 过 高 的 问题 ， 好 
像 还 没有 半点 眉目 。 这 套 系统 的 SQL 开销 比较 平均 , BRT HEE BUFFER GET 第 一 位 的 那 条 SQL 
占 了 整个 开销 的 37% 外 ， 其 他 的 SQL 占 整个 系统 BUFFER GET 的 比例 都 不 高 ， 最 多 的 也 只 是 
在 4% 左右 。 调整 这 些 SQL， 只 能 取得 有 限 的 效果 。 看 来 想 要 走 捷 径 ， 就 必须 优化 这 个 排名 第 一 
的 SQL。 于 是 我 再 次 查看 了 这 个 SQL， 它 涉及 两 张 表 : 稍 大 的 一 张 是 T_PRODUCT_INFO, 这 
张 表 的 WHERE 条 件 中 有 一 个 PRODUCT_TYPE=:P1 AND PRODUCT_CLASS=:P2 过 滤 条 件 ; 
另外 一 张 是 小 表 ， 大 概 只 有 20 多 条 记录 。 执行 计划 是 ， 在 扫描 完 两 张 表 后 ， 对 结果 集 做 散 列 连 
БИ HASH JOIN ), 在 T_PRODUCT_INFO 表 中 ,存在 一 个 复合 索引 ( PRODUCT_TYPE,PRODUCT 
_CLASS )， 执 行 计划 也 是 通过 这 个 索引 进行 范围 扫描 的 。 从 执行 计划 来 看 ， 并 没有 问题 ,平均 
每 次 返回 结果 的 记录 数 不 过 60 多 条 , 而 T PRODUCT. INFO 进行 索引 范围 扫描 找到 的 记录 接近 
700 £, T PRODUCT INFO 表 的 总 记录 数 为 800 万 ， 从 一 个 包含 800 万 条 记录 的 表 中 ,扫描 出 
700 条 记录 , 这 个 索引 的 效率 还 是 比较 高 的 。 可 是 为 什么 这 样 一 个 简单 的 SQL 会 产生 1500 多 个 
BUFFER GET 呢 ? 我 马上 联想 到 了 聚 复 因子 (clusterfactor )， 于 是 立即 查看 DBA_INDEXES 视 
图 ， 果 然 ， 这 个 索引 的 聚 徐 因 子 接近 记录 的 数量 。 如 果 肾 艇 因子 较 高 ， 在 通过 索引 范围 扫描 访 
问 表 时 ,由 于 每 个 索引 键 值 更 多 地 指向 新 数据 块 ， 因 此 会 产生 更 多 的 物理 WO， 并 导致 BUFFER 
GET 的 数量 增加 。 

我 马上 找到 郭 工 ， 了 解 这 张 表 的 用 途 。 这 张 表 是 存放 产品 资料 的 ， 客户 做 售后 服务 时 会 通过 
PRODUCT_TYPE 和 PRODUCT_CLASS 找到 符合 条 件 的 备件 ， 然 后 再 根据 库存 情况 以 及 本 次 服 
务 的 其 他 限定 条 件 , 找 出 满足 条 件 的 备件 。 这 张 表 的 数据 是 逐步 添加 的 ， 随 着 新 产品 及 其 备件 的 
出 现 ， 表 数据 也 越 来 越 多 。 以 前 这 张 表 只 有 一 两 百 万 条 记录 ， 随 着 这 几 年 的 积累 ， 记 录 数 已 经 接 
ir 1000 万 了 。 我 想 了 一 下 ， 这 张 表 的 记录 的 加 入 ， 肯 和 定 不 会 按照 PRODUCT TYPE 和 
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PRODUCT CLASS 进行 排序 ， 因 此 索引 的 聚 复 因子 较 大 也 就 不 足 为 奇 了 。 于 是 我 问 郭 工 ， 对 这 
张 表 的 访问 是 不 是 大 多 数 都 通过 PRODUCT. TYPE #1 PRODUCT. CLASS 进行 , 郭 工 想 了 想 M: 
“是 的 ， 绝 大 多 数 访问 都 是 根据 这 两 个 字段 的 条 件 ， 另 外 一 种 就 是 根据 PRODUCT ID 直接 定位 
产品 。。 PRODUCT ID 是 这 张 表 的 主键 ， 既 然 主要 的 访问 方式 只 有 这 两 种 ,那么 我 倒是 想 出 了 一 
个 优化 方案 。 
由 于 记录 的 插入 顺序 没有 按照 PRODUCT TYPE 和 PRODUCT_CLASS 排序 , 因此 索引 范围 
扫描 的 成 本 较 高 。 如 果 我 们 能 够 对 这 张 表 进 行 重 组 ,使 之 按照 这 两 个 字段 排序 , 那么 范围 扫描 的 
成 本 就 可 以 得 到 有 效 的 减少 。 采 用 如 下 的 方法 可 以 完成 这 个 优化 : 

(1) 将 原 表 重 命名 为 T_PRODUCT_INFO_OLD; 

(2) 使 用 下 列 语句 创建 新 表 ， 并 按照 PRODUCT. TYPE #1 PRODUCT CLASS ҖЕ; 

Create table t_product_info as select * from t_product_info old order by product_type,product_class; 

(3) 创建 相关 索引 及 约束 关系 ; 

(4) 分 析 表 和 索引 。 

于 是 ， 我 们 决定 今 晚 就 实施 优化 操作 。 郭 工 听 我 说 了 半天 聚 复 因 子 ， 也 没 明 白 ， 便 说 :“ 老 
白 ， 技 术 的 问题 我 就 不 管 了 ， 我 帮 你 申请 今 晚 停机 的 事情 。 这 套 系 统 晚上 就 只 有 一 些 统计 报表 ， 
所 以 在 19 点 到 21 点 之 间 都 是 可 以 停 库 的 。 如 果 你 的 操作 能 够 在 2 个 小 时 内 完成 , 停机 申请 就 没 
有 任何 问题 ， 否 则 我 就 需要 和 业务 部 门 协商 了 。” 我 想 了 想 ， 这 张 表 也 就 几 百 兆 字 节 的 大 小 ，!1 
个 小 时 肯定 能 解决 问题 了 。 


4 月 3 日 效果 不 错 


昨天 晚上 重建 了 T_PRODUCT_INFO Xe, 操作 过 程 还 是 比较 顺利 的 , 尽管 客户 申请 了 一 个 小 
时 的 停机 窗口 ,但 不 到 半 小 时 ， 整 个 操作 就 完成 了 。 原 本 计划 8 点 停机 ,但 因为 有 一 个 很 重要 的 
日 报表 要 跑 , 最 后 拖 到 了 10 点 多 才 开 始 。 在 这 段 时 间 里 , 我 又 对 BUFFER GET 和 BUFFER BUSY 
WAITS 比较 大 的 几 个 索引 进行 了 一 些 分 析 ， 发现 了 一 张 表 ， 表 的 大 小 只 有 200 MB ， 但 索引 的 大 
小 却 接近 300 MB ， 索 引 碎 片 十 分 严重 。 于 是 我 对 一 些 访 问 比 较 频繁 的 表 上 的 索引 进行 了 一 番 检 
查 ， 发 现 这 种 现象 还 是 比较 普遍 的 。 在 和 郭 工商 量 后， 我 们 决定 对 这 些 索引 进行 重建 。 

由 于 停机 时 间 比 较 充 裕 , 做 完 表 重建 后 还 有 半 个 多 小 时 , 我 又 重建 了 几 张 比较 重要 的 小 表 的 
索引 。 那 个 接近 300 MB 的 索引 ,重建 后 只 有 60 MB 多 了 。 由 于 这 套 系统 自从 上 线 后 基本 没 做 过 
重建 ， 因 此 存在 很 多 碎片 化 比较 严重 的 索引 。 我 和 郭 工 商定 在 应 用 恢复 后 ， 对 小 于 1 GB 的 访问 
比较 频繁 的 表 上 所 有 的 索引 进行 一 次 在 线 重 建 。 这 些 索引 总 计 20 多 个 , 最 大 的 有 1GB 多, 为 了 
保险 起 见 , 我 建议 在 控制 台 上 进行 索引 的 在 线 重建 工作 , 以 前 曾经 碰 到 过 由 于 网 络 中 断 导 致 重建 
失败 的 情况 ,正在 进行 的 在 线 重 建 操 作出 错 ， 正 在 被 重建 的 索引 处 于 非 正 常 状态 , 无 法 删除 , 也 
无 法 重新 继续 重建 。 最 后 只 能 通过 Metalink 上 提供 的 方法 ， 手工 删除 日 志 表 ， EHT ind$ 
中 索引 的 状态 属性 ， 才 解决 了 问题 。 

索引 重建 后 , 我 又 对 相关 的 表 进 行 了 CASCADE=>TRUE 的 分 析 ， 完 成 时 已 经 是 凌晨 两 点 多 
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了 。 开 发 商用 预先 准备 好 的 十 几 条 关键 业务 相关 的 SQL 做 了 一 次 测试 ,确认 了 执行 计划 都 是 正 
确 的 。 完 成 这 些 工 作 后 ， 郭 工 还 是 不 太 放 心 ， 劝 我 留 下 ， 万 一 明天 早上 有 事 ， 可 以 马上 处 理 。 这 
也 是 我 经 常 遇 到 的 ， 于 是 我 很 痛快 地 答应 了 。 

第 二 天 早上 我 没有 接 到 郭 工 的 电话 ,看 样子 昨 晚 的 调整 并 没有 产生 负面 影响 。 午饭 后 ,我 来 
到 办 公 室 查看 系统 的 情况 ，CPU 使 用 率 只 有 60% 左 右 ， 虽 然 现 在 是 业务 空闲 时 段 ， 不 过 前 几 天 
这 个 时 间 段 的 CPU 使 用 率 都 在 80% ~ 90% 的 高 位 ， 这 说 明 昨 天 的 工作 还 是 有 一 定 效 果 的 。 听 小 
马 说 ， 上 午 CPU 使 用 率 也 一 直 比 较 稳定 ， 在 80% ~ 85% 之 间 ， 很 少 有 达到 90% 的 情况 。 我 查看 
了 OSW 的 监控 数据 ， 确 实 , 今天 上 午 的 CPU 使 用 率 都 在 80% 左 右 ， 只 有 在 10 点 半 左 右 出 现 了 
ЛАУ 90% ~ 95% 之 间 的 采样 点 。 我 马上 生成 了 一 个 STATSPACK 报告 ， 查 看 那 条 访问 
T PRODUCT INFO 的 SQL 的 开销 情况 ， 每 秒 的 逻辑 读 和 物理 读 都 下 降 了 40% 多， 执行 时 间 少 
了 50% 多 。 昨 天 的 表 重 组 起 到 了 不 错 的 效果 ,虽然 这 条 SQL 的 BUFFER GET 还 是 排 在 前 五 , 不 
过 占 整 个 系统 BUFFER GET 的 比例 已 经 下 降 到 了 7% 左 右 。 这 样 看 来 ， 如果 下 午 能 够 保持 这 种 状 
态 ， 本 次 优化 工作 就 可 以 告 一 段落 了 。 

下 午 3 点 多 ， 郭 工 回 到 办 公 室 ,我 们 约定 下 午 4 点 讨论 优化 报告 ， 如 果 没 有 问题 ， 大 家 就 签 
署 一 个 工作 日 志 ， 然 后 结束 本 次 优化 工作 。 本 来 商定 的 是 我 和 郭 工 、 小 马 一 起 开 个 小 会 ， 谁 料 3 
点 半 时 郭 工 突然 通知 我 , 他 们 业务 中 心 的 刘 主 任 也 要 参加 这 次 会 议 。 考 虑 到 刘 主 任 是 负责 业务 的 ， 
对 技术 并 不 在 行 ， 如 果 仅 仅 讨论 这 份 不 到 10 页 的 优化 工作 报告 ， 效 果 肯 定 不 好 ， 于 是 我 做 了 一 
份 PPT, 简单 介绍 了 本 次 优化 的 背景 、 目 的 、 实 施 方案 以 及 达到 的 效果 , 为 了 更 直观 地 展示 效果 ， 
还 使 用 柱状 图 和 折线 图 比 对 了 优化 前 、 后 系统 的 资源 消耗 和 性 能 的 差异 ， 从 图 表 上 看 ,这 次 优化 
做 得 还 算 成 功 。 

总 结 会 上 ,我 向 大 家 介绍 了 优化 的 全 过 程 和 取得 的 丰硕 成 果 , 刘 主 任 听 后 也 很 满意 。 他 在 开 
会 前 已 经 了 解 过 营业 员 对 系统 的 反馈 , 时 就 听 说 他 是 十 分 严 间 的 人 ， 从 这 件 事 来 看 确实 如 此 。 还 
好 我 准备 了 PPT, 列 出 了 具体 的 数字 ， 否则 会 议 的 效果 肯定 大 打折 扣 。 本 以 为 介绍 完 这 些 情 况 会 
议 就 结束 了 ， 没 想到 我 正 等 着 刘 主 任 的 客 套话 时 ， 他 突然 提出 了 一 个 问题 :“ 老 白 ， 从 你 的 报告 
里 我 感觉 在 这 次 优化 中 ， 起 到 最 重要 作用 的 就 是 表 的 重建 ， 是 不 是 ?” C 

我 想 都 设想 就 回答 说 是 , 这 次 优化 最 关键 的 确实 就 是 表 重组 , 通过 重组 减少 了 索引 范围 扫描 
的 开销 。 还 没 等 我 继续 解释 ， 刘 主任 又 接着 问 到 :“ 这 回 的 问题 是 解决 了 ， 如 果 过 一 段 时 间 ， 这 
张 表 的 性 能 又 下 降 了 ， 我们 的 系统 是 不 是 又 会 出 现 类 似 的 问题 ? ” 


张 表 刚 刚 重 建 过 ， 佑 计 在 半年 之 内 问题 不 会 太 大 。 

刘 主 任 眉 头 一 煞 :“ 这 张 表 会 越 来 越 大 ， 那么 随 着 时 间 的 推移 ， 这 张 表 重建 的 难度 也 将 越 来 
越 大 ， 有 没有 更 好 的 办 法 能 够 确保 重建 工作 在 较 短 的 时 间 内 完成 呢 ? 重建 工作 会 对 业务 造成 影 
响 ， 最 好 每 次 重建 的 停机 时 间 都 能 够 控制 在 30 分 钟 以 内 。 

这 个 问题 我 确实 没有 考虑 过 ,因为 目前 这 张 表 只 有 不 过 800 多 万 条 记录 。 但 是 它 的 增长 速度 
十 分 快 , 今年 年 底 前 记录 数 可 能 就 会 翻番 ， 如 果 每 次 都 去 做 全 表 重 组 , 确实 有 点 麻烦 。 于 是 我 向 
郭 工 询问 这 张 表 的 数据 特点 , 郭 工 说 , 这 张 表 的 数据 一 般 在 插入 后 就 很 少 会 被 修改 ,除非 是 某 个 
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产品 或 者 备件 的 状态 发 生 了 变化 ， 比 如 某 个 产品 退 市 了 , 会 修改 这 个 产品 的 状态 位 。 原 则 上 ,这 
张 表 的 数据 是 只 增加 不 删除 的 。 

根据 郭 工 的 描述 , 我 认为 通过 分 区 表 的 方式 就 能 够 解决 这 个 问题 。 如 果 我 们 用 产品 输入 时 间 
作为 分 区 关键 字 , 那么 就 可 以 根据 产品 输入 的 时 间 将 表 分 为 若干 个 分 区 ,如 果 每 个 分 区 包含 6 个 
月 的 数据 ,那么 大 约会 有 500 万 条 记录 。 如 果 我 们 将 索引 创建 为 本 地 索引 , 那么 就 可 以 每 隔 半年 
重组 一 个 分 区 , 每 次 重组 的 时 间 肯 定 不 会 超过 半 小 时 。 这 样 的 话 ， 虽 然 索引 范围 扫描 的 开销 要 略 
大 于 现在 的 普通 表 的 模式 ， 但 是 能 够 很 好 地 解决 长 期 维护 问题 。 

这 个 建议 提出 后 ， 郭 工 感到 有 些 茫 然 ， 他 觉得 使 用 本 地 索引 后 可 能 会 影响 范围 扫描 的 性 能 ， 
本 来 是 扫描 一 个 全 局 索引 ， 而 现在 要 对 所 有 的 分 区 进行 扫描 ， 这 样 是 不 是 会 增加 SQL 的 开销 ， 
还 不 如 把 索引 建成 全 局 索引 。 

我 解释 道 :“ 如 果 建 成 全 局 索引 ， 那 么 索引 扫描 的 效率 在 分 区 前 后 的 差异 相当 小 ， 基 本 上 可 
以 忽略 不 计 。 但 是 每 次 重组 分 区 时 ， 全 局 索引 都 需要 重建 ， 随 着 表 的 数据 量 增加 ,索引 重建 的 时 
间 也 会 越 来 越 长 ， 这 样 就 会 影响 停机 时 间 。” 

确实 , 这 是 一 种 两 难 的 选择 , 但 在 便于 维护 和 更 好 的 性 能 这 两 方面 ,一 般 来 说 ,选择 便于 维 
护 会 更 好 。 维护 不 是 简单 的 加 、 Ж, Ж, ER, 理论 上 的 最 优选 择 往往 不 是 实际 工作 中 的 最 佳 答案 。 
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分 区 表 技 术 的 引入 是 Oracle 在 海量 数据 处 理 方面 一 项 很 大 的 进步 ， 它 已 成 为 海量 数据 管理 
中 十 分 重要 的 技术 手段 。 通 过 分 区 表 技 术 ， 我 们 可 以 把 一 张 很 大 的 表 分 为 多 个 较 小 且 可 管理 的 
分 区 ， 从 而 规避 性 能 和 维护 方面 的 问题 。 很 多 DBA 对 分 区 表 的 了 解 并 不 深入 ， 因 此 在 使 用 分 区 
表 技术 的 过 程 中 会 遇 到 很 多 问题 。 

在 本 章 中 ， 老 白 将 和 大 家 一 起 从 分 区 表 最 为 本 质 的 特性 出 发 ， 学 习 如 何 使 用 、 维 护 分 区 表 ， 
从 而 使 分 区 表 技 术 在 优化 中 发 挥 最 大 的 效能 。 
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分 区 表 技 术 是 Oracle 8.0 推出 的 ， 到 现在 为 止 已 经 有 十 多 年 ， 不 过 直到 近 几 年 ， 才 在 中 国 真 
正 被 重视 和 使 用 。 分 区 表 的 出 现 是 VLDB 系统 发 展 的 必然 结果 ， 随 着 数据 量 的 增加 ， 分 区 表 的 
作用 也 日 益 凸 显 。 实 际 上 ， 早 期 的 VLDB 系统 数据 量 并 不 大 ， 只 有 1 ~ 200 GB 。 最 早 有 分 区 表 业 
务 需求 的 是 电信 和 移动 的 计 费 系统 ,每 个 月 几 千 万 条 话 单 的 数据 ， 如 果 放 在 一 张 表 里 , 处理 起 来 
肯定 会 出 现 问题 。 通 信行 业 集成 商 采用 的 解决 方案 是 分 表 ， 将 不 同 账 期 的 数据 放 在 不 同 的 表 中 。 
分 表 虽 然 有 效 地 解决 了 处 理 这 些 数据 时 可 能 出 现 的 性 能 问题 , 但 也 给 开发 团队 带 来 了 另外 一 个 问 
题 ， 就 是 应 用 开发 的 复杂 度 问 题 。 同 一 个 业务 的 数据 可 能 存放 在 多 张 名 称 类 似 的 表 中 , 用 户 需要 
在 多 张 表 中 查询 数据 ， 这 使 得 应 用 的 复杂 度 大 幅 增 加 。 

分 区 表 技 术 有 效 地 解决 了 这 两 方面 的 问题 ， 既 保证 了 数据 的 分 区 存放 ， 确 保 每 个 分 区 可 以 
独立 访问 ， 同 时 又 可 以 对 整个 表 中 的 各 个 分 区 进行 透明 访问 ， 并 且 不 需要 对 原来 的 应 用 程序 进 
行 调整 。 分 区 表 技 术 是 很 适合 在 运营 商 的 计 费 账 务 系统 中 使 用 的 ， 但 是 国内 早期 的 成 功 应 用 并 
不 是 出 现在 上 述 系 统 中 。 在 2000 年 到 2006 年 这 段 时 间 里 ， 我 做 了 不 少 大 型 的 系统 性 能 优化 项 
目 ， 在 这 些 项 目 中 无 一 例外 地 都 使 用 了 表 分 区 的 技术 ， 通 过 将 普通 表 转 换 为 分 区 表 或 者 调整 分 
区 表 的 分 区 方式 来 对 系统 进行 优化 。 在 实际 应 用 过 程 中 ， 这 种 调整 在 绝 大 多 数 情 况 下 都 取得 了 
不 错 的 效果 。 

近年 来 , 越 来 越 多 的 软件 开发 厂商 开始 在 自己 的 系统 中 使 用 分 区 表 技 术 , 并 从 这 种 技术 中 获 
得 了 不 错 的 效果 。 不 过 还 是 有 一 些 用 户 对 分 区 表 技 术 仍然 十 分 抵触 ,认为 该 技术 增加 了 维护 的 复 
杂 性 。 在 接 下 来 的 内 容 中 ， 我 们 就 从 多 个 角度 来 了 解 分 区 表 。 
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分 区 表 包 含 多 种 类 型 ， 比 如 范围 分 区 、HASH 分 区 、 复 合 分 区 、 列 表 分 区 等 , 为 了 简化 起 见 ， 


我 们 先 从 使 月 


表 开 始 讲述 ， 如 代码 清单 12-1 所 示 。 
代码 清单 12-1 


SQL> c 


Table 


reate table XJTPAR [ 
id integer not null, 
txt varchar2(100), 
tdate date 


) 
PARTITION BY RANGE (10) 


PARTITION XJPART 01 VALUES LESS THAN (10000) 
PARTITION XJPART 02 VALUES LESS THAN (20000) 
PARTITION XJPART 03 VALUES LESS THAN (30000) 
PARTITION XJPART 04 VALUES LESS THAN (40000) 


|; 


created. 


日 最 为 普遍 的 范围 分 区 说 起 。 为 了 便于 大 家 理解 , 这 里 先 从 创建 一 张 范围 分 区 的 分 区 


这 样 就 创建 了 一 张 分 区 表 XJTPAR, 这 张 表 包含 4 个 分 区 , 分 别 是 XJPART 01, XJPART 02, 
XJPART 03 和 XJPART_04。 首 先 来 看 一 看 ， 这 些 表 和 分 区 是 否 为 独立 的 对 象 ， 我 们 可 以 从 
DBA_OBJECTS 里 查找 : 


SQL> c 
SQL» с 
SQL> s 
SQL» s 


0BJ ECT 
124950 
124951 
124952 
124953 
124949 


ol object name format а10 trunc 
ol subobject name format а12 trunc 
et line 132 


elect object id,object name,subobject name,object type,data object id from 
dba objects where obj ect_name=' XJ] TPAR' 


.|D OBJECT_NAM 


SUBOBJ ECT NA 


OBJ ECT TYPE 


DATA OBJECT 10 


XJ PART 01 TABLE 
XJ PART 02 TABLE 
XJ PART 03 TABLE 
XJ PART 04 TABLE 

TABLE 


PARTI TI ON 
PARTI TI ON 
PARTI TI ON 
PARTI TI ON 


124950 
124951 
124952 
124953 


从 上 述 结果 可 以 看 出 ， 分 区 表 XJTPAR 是 一 个 对 象 ， ID 是 124949， 而 每 个 分 区 则 分 别 是 一 


个 子 对 象 。 实 际 上 ， 每 个 分 区 都 是 一 个 独立 的 子 对 象 。Oracle MARI, BAA 


象 概念 ， 又 使 分 区 表 的 每 个 分 区 有 了 独立 的 对 象 资格 ， 并 |] 


ЕЮ Г ЖОН НДА 
旦 每 个 子 分 区 都 有 自己 独立 的 


РАТА ОВЈЕСТ ID， 从 而 使 每 个 分 区 有 了 独立 的 段 。 在 这 里 ， 细 心 的 朋友 可 能 会 发 现 一 个 问题 ， 
表 分 区 的 DATA. OBJECT. ID 都 是 存在 的 ， 反 而 是 XJTPAR 的 РАТА OBJECT ID 是 空 的 。 习 
E, 分 区 表 的 数据 是 存储 在 每 个 分 区 中 的 , 表 是 不 需要 存储 数据 的 ， 因此 也 就 不 需要 为 表 自 身分 
配 段 。 我 们 可 以 通过 DBA_SEGMENTS 验证 这 个 结论 : 


SQL» c 
SQL» c 


0| segment name format al0 trunc 
0| subsegment name format al2 trunc 
SQL» select segment name,partition name,segment type,blocks from dba segments where 
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segment name ='XJTPAR' 

SEGMENT NA PARTITI ON NAME SEGMENT TYPE BLOCKS 
XJ TPAR XJ PART 01 TABLE PARTI TI ON 8 
XJ TPAR XJ PART 02 TABLE PARTI TI ON 8 
XJ TPAR XJ PART 03 TABLE PARTI TI ON 8 
XJ TPAR XJ PART 04 TABLE PARTI TI ON 8 


我 们 可 以 看 到 ， 对 于 XJTPAR 这 张 分 区 表 ， 每 个 分 区 都 有 一 个 段 ， 而 表 本 身 并 没有 段 存在 。 

因此 ， 我 们 可 以 大 胆 推断， 每 个 表 分 区 (TABLE PARTITION ) 本 身 都 有 独立 的 段 头 ， 这 一 
点 可 以 通过 DATA BLOCK DUMP 来 进行 验证 。 首 先 我 们 通过 DBA_EXTENTS 来 查看 这 几 个 段 
的 扩展 情况 : 


SQL» select segment name,partition name,blocks,file id,block id from dba extents 
where segment name z'XJTPAR' 


SEGMENT NA PARTITI ОМ NAME BLOCKS FILE ID BLOCK ID 
XJ TPAR XJ PART 01 8 4 521 
XJ TPAR XJ PART 02 8 4 529 
XJ TPAR XJ PART 03 8 4 531 
XJ TPAR XJ PART 04 8 4 545 


接 下 来 ， 通 过 DUMP ХЈРАВТ 01 和 ХЈРАВТ 02 的 前 几 个 块 来 验证 我 们 的 推断 : 
SQL» alter system dump datafile 4 block min 521 block max 524 


System altered. 
SQL» alter system dump datafile 4 block min 529 block max 533 


System altered 
我 们 可 以 从 TRACE 文件 中 看 到 : 


Start dump data blocks tsn: 4 files: 4 mnblk 521 maxblk 524 
buffer tsn: 4 rdba: 0x01000209 (4/521) 

scn: 0x0000.055f126c seq: 0x01 flg: 0x04 tail: 0x126c2001 
frmt: 0x02 chkval: 0x7b74 type: Ox20=FIRST LEVEL BITMAP BLOCK 
Hex dump of block: st=0, typ foundzl 


buffer tsn: 4 rdba: 0x0100020a (4/522) 

scn: 0x0000.055f126b seq: 0x01 flg: 0x04 tail: 0x126b2101 
frmt: 0x02 chkval: 0x6964 type: Ox21=SECOND LEVEL BITMAP BLOCK 
Hex dump of block: st=0, typ found=1l 


buffer tsn: 4 rdba: 0x0100020b (4/523) 
scn: 0x0000.055f126c seq: 0x01 flg: 0x04 tail: 0x126c2301 
frmt: 0x02 chkval: 0x46c7 type: Ox23=PAGETABLE SEGMENT HEADER 


38 $123 理解 分 区 表 


Hex dump of block: st=0, typ_found=1 


buffer tsn: 4 rdba: 0x0100020c (4/524) 

scn: 0x0000.001d78df seq: 0x01 flg: 0x06 tail: 0x78df 0601 
frmt: 0x02 chkval: 0x55bc type: 0x06=trans data 

Hex dump of block: st=0, typ found=1l 


对 于 子 分 区 XJPART_01， 其 存储 结构 和 普通 表 一 样 : 首先 是 1STBMB ， 然 后 是 2ND BMB, 


第 3 个 块 是 段 头 。XJPART 02 的 结构 也 是 类 似 的 : 


Start dump data blocks tsn: 4 files: 4 minblk 529 maxblk 533 
buffer tsn: 4 rdba: 0x01000211 (4/529) 

scn: 0x0000.055f1287 seq: 0x01 flg: 0x04 tail: 0x12872001 
frmt: 0x02 chkval: Ox7b75 type: Ox20=FIRST LEVEL BITMAP BLOC 


buffer tsn: 4 rdba: 0x01000212 (4/530) 
scn: 0x0000.055f1286 seq: 0x01 flg: 0x04 tail: 0x12862101 


K 


frmt: 0x02 chkval: 0x697d type: Ox21=SECOND LEVEL BITMAP BLOCK 


buffer tsn: 4 rdba: 0x01000213 (4/531) 
5сп: 0x0000.055f1287 seq: 0x01 flg: 0x04 tail: 0x12872301 
frmt: 0x02 chkval: 0х46с6 type: 0x23zPAGETABLE SEGMENT HEADE 


每 个 分 区 都 具有 独立 的 和 表 一 样 的 存储 结构 ,拥有 独立 的 段 头 、 位 


R 


图 以 及 高 水 位 标志 。 这 就 


决定 了 在 大 并 发 量 插入 数据 时 ， 分 区 表 在 段 头 、BMB 和 高 水 位 推进 方面 会 有 更 大 的 优势 。 
另外 一 方面 , 由 于 每 个 子 分 区 都 拥有 和 普通 表 一 样 的 段 结构 , 因此 分 区 表 某 个 分 区 的 扫描 性 
能 和 由 一 张 分 区 表 划 分 而 来 的 每 张 独立 表 的 扫描 性 能 是 没有 差异 的 。 说 到 这 里 , 可 能 有 些 朋 友 会 
有 不 同 的 看 法 , 认为 普通 的 分 表 访 问 数据 时 ,不 需要 判断 数据 在 哪 张 表 中 ， 而 分 区 表 则 需要 判断 
数据 在 哪个 分 区 中 ， 这 样 效率 表 定 会 受到 影响 。 事 实 上 ， 扫描 操 作 到 底 扫 描 哪个 段 ， 是 在 SQL 
分 析 时 就 确定 了 的 ， 当 然 存在 分 区 对 象 的 SQL 分析 需要 访问 更 多 的 数据 字典 ， 以 确定 执行 计划 ， 


这 一 点 是 肯定 的 ， 不 过 这 点 差异 我 们 可 以 暂时 忽略 不 计 。 


К. 史 来 说 ，Oracle 8.0 是 最 早 推出 分 区 表 技 术 的 版 本 ， 不 过 这 个 版 本 只 支 
围 分 区 。Oracle 8i 增加 了 HASH 分 区 ,同时 开始 支持 子 分 区 ,另外 ，8i 版 本 还 支持 第 一 层 
. 第 二 层 为 HASH 分 区 的 复合 分 区 表 。Oracle 9.0.1 开始 支持 列表 (LIST) 分 区 ， 


9.0.2 开始 支持 范围 分 区 作为 第 一 层 ， 列 表 分 区 作为 第 二 层 的 复合 分 区 。 
Range-List 分 区 。 代 码 清 单 12-2 是 一 个 Range-List 


种 有 些 怪 异 却 十 分 有 用 的 混合 模式 分 区 


Oracle 9.2 开始 支持 一 


分 区 的 示例 (该 示例 来 自 于 MOS 文档 Range List Partitioning - Oracle 9.2 Enhancement [ID 


209368.1] )。 
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代码 清单 12-2 


CREATE TABLE empdata 
( empno number， 
ename varchar2( 20), 
deptno number, 
continent varchar2(6), 
hiredate date, 
job varchar2(10), 
Salary number) 
PARTITION BY RANGE (deptno 


SUBPARTI TION BY LIST (continent) 
(PARTITION di emp VALUES LESS THAN (100 
(SUBPARTITION 01 соп1 VALUES ('ASIA', 'AUST'), 
SUBPARTI TION dl con2 VALUES ('AMER'), 
SUBPARTITION dl con3 VALUES (AFRICA 
SUBPARTITION dl con4 VALUES ('EUROPE')), 
PARTITION d2 emp VALUES LESS THA maxval ue) 
(SUBPARTITION d2 conl VALUES ('ASIA', 'AUST'), 
SUBPARTI TION d2 con2 VALUES ('AMER'), 
SUBPARTITION d2 con3 VALUES (AFRICA 
SUBPARTITION d2 con4 VALUES (' EUROPE']) 


); 
Oracle 10g 继续 对 分 区 表 的 功能 进行 扩展 ， 最 大 的 变化 就 是 开始 支持 索引 组 织 表 的 分 区 。 代 
码 清单 12-3 的 示例 同样 来 自 于 MOS ( Partitioning Enhancements in Oracle 10g [ID 276158.1] )。 


代码 清单 12-3 


SQL> CREATE TABLE sales [ 

acct no NUMBER(5),acct_ name CHAR(30),amount of sale NUMBER( 6) 
week no І NTEGER,sale details VARCHAR2(1000) 

PRIMARY KEY (acct no, acct name, week no)) 

ORGANI ZATION INDEX INCLUDING week no 

OVERFLOW tablespace overflow here 

PARTITION BY LIST (week no) ( 

PARTITION part1234 VALUES (1, 2, 3, 4) tablespace Ё51, 
PARTITION part5678 VALUES (5, 6, 7, 8) tablespace tsl， 
PARTITION partdefault VALUES (DEFAULT) tablespace ts1) 


Oracle 11g 在 分 区 表 技 术 方 面 又 有 了 新 的 扩充 ， 主 要 包括 以 下 几 个 方面 (这 里 仅 对 11g 版 本 
分 区 表 的 新 特性 做 简单 的 描述 ， 关 于 lle 版 本 分 区 表 更 详细 的 信息 请 参考 MOS 文档 118 
Partitioning Enhancements [ID 452447.1] )。 
а 系统 自动 分 区 表 。 这 种 分 区 表 和 普通 分 区 表 不 同 , 没有 分 区 主键 ,用 户 可 以 通过 在 INSERT 
操作 中 指定 分 区 来 把 数据 插入 到 某 个 分 区 中 ,一 般 在 OLAP 系统 中 使 用 , OLTP 较 少 使 用 。 
这 种 分 区 的 另外 一 个 意义 是 打 散 数据 ， 减 少 冲突 ， 这 个 特性 在 RAC 上 有 用 武之 地 。 
О 间隔 分 区 (interval partitioning )。 这 个 功能 对 于 那些 觉得 维护 分 区 表 比 较 头 痛 的 朋友 十 分 
有 用 ， 通 过 这 个 新 的 分 区 功能 ，DBA 可 以 定义 分 区 主键 增长 的 步 长 ( 间隔 ), Oracle 会 在 
需要 时 自动 创建 新 的 分 区 。 
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а 复合 分 区 种 类 的 扩充 。 在 11g 版 本 之 前 , 复合 分 区 只 支持 Range-Hash、Range-List 这 两 种 
方式 。 而 在 11g 版 本 中 , 复合 分 区 还 支持 Range-Range, List-Range, List-Hash 和 List-List 
方式 ， 可 以 说 ， 我 们 能 想到 的 复合 分 区 种 类 ， 基 本 上 都 文 持 了 。 

口 虚拟 列 分 区 。 虚 拟 列 的 引入 使 分 区 更 加 接近 业务 ， 由 于 虚拟 列 可 以 通过 实际 列 的 运算 得 

到 ， 因 此 我 们 可 以 设计 更 加 贴近 业务 的 分 区 模式 。 

о 引用 分 区 (reference partitioning )。 顾 名 思 义 , 这 种 分 区 表 和 主 外 键 关 联 有 关 。 比 如 ，order 
表 和 order. item 表 是 主 从 关系 的 ，order 表 按 照 order. date 分 为 4 个 区 , 那么 order. item 表 
就 可 以 根据 外 键 定义 为 引用 分 区 ， 这 样 从 表 就 会 根据 主 表 的 分 区 方式 来 进行 分 区 。 
PARTITION BY REFERENCE (order\_items\ fk) 

а 支持 系统 管理 索引 的 列表 分 区 ( System-Managed Indexes for List Partitioning ), № 11.2 版 

本 开始 ， 列 表 分 区 支持 系统 管理 的 域 索 引 (domain index )。 

对 于 分 区 表 的 使 用 ,网络 上 存在 很 多 不 同 的 声音 ， 讲 贬 不 一 。 实 际 上 ,任何 一 种 技术 都 是 有 
其 使 用 价值 的 ， 在 不 同 的 场合 ， 可 能 会 有 不 同 的 效果 。 这 些 年 来 , 分 区 表 的 优点 得 到 了 广大 用 户 
的 认可 , 但 是 到 底 多 大 的 表 才 需 要 分 区 ?对 于 这 个 问题 ,网 络 上 也 存在 很 多 观点 , 但 老 白 对 这 些 
观点 都 不 太 赞同 。 我们 应 该 根据 具体 情况 ， 而 不 是 表 的 大 小 ,来 决定 是 否 使 用 分 区 表 。 在 某 些 场 
合 ,， 即 使 对 一 张 只 有 几 千 字 节 的 表 进 行 分 区 也 是 有 意义 的 ， 比 如 ,一 张 表 的 并 发 更 新 很 频繁 ， 虽 
然 这 张 表 并 不 大 ， 但 是 表 上 所 有 数据 块 的 buffer busy waits 等 待 却 十 分 严重 。 在 这 种 情况 下 ， 如 
果 我 们 将 它 设 计 为 HASH 分 区 表 ， 那 么 对 于 缓解 BBW 等 待 是 很 有 帮助 的 。 

不 同类 型 的 分 区 表 有 其 不 同 的 应 用 场合 。 在 某 些 场合 , 使 用 分 区 表 是 为 了 便于 维护 , 将 表 划 
分 为 多 个 分 区 , 使 索引 重建 和 碎片 整理 更 加 便捷 ; 在 男 一 些 场 合 , 使 用 分 区 表 是 为 了 在 全 表 扫 描 
时 进行 分 区 裁剪 ， 此 时 需要 严格 按照 WHERE 语句 的 裁剪 条 件 来 进行 分 区 ; 而 在 其 他 一 些 场 合 ， 
使 用 分 区 表 则 是 为 了 便于 历史 数据 归档 ， 这 种 分 区 表 一 般 会 选择 某 个 时 间 字 有 段 作为 分 区 主键 。 

本 节 的 最 后 ， 老 白 来 介绍 一 张 只 有 几 百 条 记录 的 分 区 表 。 这 是 某 运 营 商 系统 中 的 一 张 表 , 它 
占用 了 两 三 个 数据 块 , 包含 了 仅 有 的 几 个 统计 字段 , 但 大 量 的 并 发 进程 ( 数 百 个 ) 会 实时 更 新 这 
张 表 上 的 一 些 统计 信息 。 每 当 系 统 业 务 高 峰 时 ，TOP5 EVENTS 内 排 在 前 两 位 的 等 待 事件 中 都 会 
出 现 热 块 冲突 。 为 了 解决 这 个 问题 ， 老 白 将 这 张 表 设计 为 分 区 表 ， 并 将 这 100 多 条 记录 打 散 到 
128 个 数据 块 中 ， 这 一 极端 的 做 法 获得 了 良好 的 效果 ， 热 块 冲突 的 问题 解决 了 。 
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顾名思义 ,海量 数据 最 大 的 特点 就 是 数据 量 多 ， 男 外 ， 其 扫描 开销 和 数据 维护 难度 也 很 大 。 
对 于 海量 数据 的 管理 , 我 们 主要 会 从 数据 归档 、 数 据 扫描 效率 、 数 据 并 发 装载 性 能 等 方面 去 考虑 。 
在 不 同 的 应 用 场合 中 ， 设 计 分 区 表 的 类 别 、 选 择 分 区 主键 、 定 义 分 区 粒度 都 是 十 分 关键 的 。 
如 果 我 们 不 能 很 好 地 掌握 这 些 技术 , 那么 即使 使 用 了 分 区 表 , 也 可 能 无 法 达到 预想 的 目的 。 本 节 
将 从 海量 数据 系统 的 特点 人 手 , 介绍 分 区 表 技 术 的 应 用 场合 , 以 及 如 何 根据 应 用 特点 进行 适当 的 


设计 。 
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12.2.1 分 区 表 和 历史 数据 归档 


历史 数据 归档 是 任何 一 个 成 熟 的 应 用 系统 都 必须 具备 的 。 在 一 二 十 年 前 , 软件 都 带 有 数据 备 
份 和 数据 归档 功能 ,因为 那 时 大 家 对 数据 库 技术 的 研究 还 不 透彻 , 所 以 这 些 功 能 都 必须 设计 在 软 
件 中 。 另 外 ， 由 于 那 时 候 的 磁盘 很 小 ， 系 统 的 存储 容量 和 CPU 处 理 能 力 都 很 有 限 ， 因 此 如 果 数 
据 不 及 时 归档 ， 就 很 容易 出 现 性 能 瓶颈 。 随 着 数据 库 和 计算 机 软 、 硬 件 技术 的 高 速 发 展 ， 以 及 计 
算 机 硬件 价格 的 大 幅 下 降 ， 各 种 IT 辅助 系统 日 渐 完善 ， 如 今 大 多 数 系统 都 可 以 采用 自 带 的 或 者 
第 三 方 的 产品 进行 备份 和 容 灾 ,因此 开发 厂商 对 这 方面 的 认识 逐渐 淡薄 , 数据 归档 也 逐渐 成 为 可 
有 可 无 的 功能 。 但 随 着 系统 上 线 时 间 的 推移 ， 数 据 量 越 来 越 大 ， 系 统 中 的 碎片 也 越 来 越 多 ， 系 统 
开销 就 会 越 来 越 大 , 这 也 是 我 们 的 系统 经 常 随 着 上 线 时 间 的 推移 而 变 得 越 来 越 慢 的 主要 原因 。 因 
此 数据 归档 对 于 任何 一 套 系统 来 说 ,都 是 十 分 重要 的 ， 从 老 白 多 年 的 项 目 优 化 经 验 来 看 ， 至少 有 
60% 的 系统 可 以 通过 数据 归档 来 解决 问题 。 

既然 数据 归档 有 这 么 好 的 效果 , 我 们 就 应 该 经 常 对 自己 的 系统 进行 数据 归档 。 但 接着 下 一 个 
问题 就 来 了 , 在 有 数据 需要 归档 时 ， 是 不 是 需要 采用 分 区 表 呢 ? 答案 是 十 分 肯定 的 ， 分 区 表 很 适 
合 需 要 定期 进行 数据 归档 的 系统 。 对 于 需要 历史 数据 归档 的 表 , 第 一 层 分 区 最 好 能 够 按照 时 间 字 
EE XS 

下 面 来 看 一 个 案例 。 有 一 张 名 为 ACC. ITEM. CUR 的 表 , 它 是 按照 АСС DATE 字段 分 区 的 ， 
每 个 月 我 们 都 会 对 其 历史 数据 进行 归档 ， 归 档 的 方式 是 从 生产 表 上 将 数据 导入 到 历史 表 
ACC ITEM HIS 中 ， 然 后 在 生产 表 上 删除 这 些 数 据 。 然 而 ， 如 果 采 用 传统 的 方法 ， 我 们 需要 首 
先 将 数据 插入 ACC_ITEM_HIS， 然 后 用 DELETE 语句 删除 相关 的 数据 。 如 果 每 个 月 归档 的 数据 
是 数 千 万 ， 甚 至 上 亿 , 那么 这 项 归档 工作 的 开销 就 是 巨大 的 。 

如 果 比 较 幸 运 ，ACC_ITEM_CUR 是 一 张 按 照 АСС DATE 分 区 的 分 区 表 ， 那 么 我 们 就 可 以 
采用 一 种 更 加 快捷 且 开 销 较 小 的 解决 方案 了 ， 这 个 方案 就 是 分 区 交换 (exchange partition )。 分 区 
交换 是 随 着 分 区 表 在 Oracle 8.0 中 出 现 的 技术 ， 其 基本 原理 十 分 简单 ， 就 是 通过 修改 数据 字典 中 
的 定义 ， 将 两 个 段 进 行 交换 。 说 得 具体 一 点 就 是 先 创建 一 个 空 段 (一 张 表 )， 然 后 将 分 区 表 的 段 
和 这 张 表 的 段 进行 交换 ,在 这 个 过 程 中 ,只 需要 修改 相关 段 的 DBA_OBJECT_ID, 而 不 需要 进行 
实际 的 数据 交换 。 通 过 分 区 交换 , 需要 归档 的 分 区 的 段 被 交换 到 表 上 ,而 ACC_ITEM_CUR 的 这 
个 分 区 就 变 为 空 分 区 了 。 下 一 步 ， 我 们 再 做 一 次 分 区 交换 ， 将 表 上 包含 数据 的 段 交 换 到 
АСС ITEM HIS 表 的 某 个 分 区 上 ， 然 后 再 删除 АСС ITEM CUR 上 的 空 分 区 ， 这 样 归档 操作 就 
完成 了 ， 最 后 进行 分 区 表 的 全 局 索引 重建 操作 。 

随 着 Oracle 版 本 的 提升 ， 分 区 交换 技术 也 进一步 成 熟 , 在 10g 和 11g 版 本 中 ， 交 换 分 区 
支持 的 分 区 类 型 进一步 增加 ， 对 本 地 索引 交换 的 支持 也 日 益 完 善 。 不 过 在 使 用 分 区 交换 技术 
时 ， 也 会 面临 全 局 索引 的 问题 。 由 于 全 局 索引 可 能 失效 ， 所 以 在 采用 这 种 技术 进行 归档 的 表 
上 ， 应 尽 可 能 减少 全 局 索引 的 使 用 ， 甚 至 在 一 些 超 大 的 表 上 ， 应 避免 使 用 全 局 索引 ， 最 好 将 
包括 主键 在 内 的 索引 都 设计 为 分 区 索引 。 下 面 我 们 通过 代码 清单 12-4 的 示例 来 回顾 一 下 本 节 
介绍 的 技术 。 
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代码 清单 12-4 


drop table acc item cur 
drop table acc item ex; 
drop table acc item his 


alter session set nls date formatz' yyyy- mm- dd hh24: mi:ss' 
Жа Ж 
CREATE TABLE acc item cur 
( acc item number 
acc item desc varchar2(20) 
acc date date 
area code varchar2(6) 
) 
PARTITION BY RANGE [acc_date) 
SUBPARTITION BY LIST (area_code 
(PARTITION d1 VALUES LESS THAN ('2012-02-1 00: 00: 00' 
(SUBPARTITION 01 conl VALUES ('ASIA', 'AUST'), 


SUBPARTI TION di con2 VALUES ('AMER') 
SUBPARTITION dl con3 VALUES ( AFRICA') 
SUBPARTITION dl con4 VALUES ( EUROPE']), 
PARTITION d2 VALUES LESS THAN ('2012-03-1 00:00:00' 
(SUBPARTITION d2 conl VALUES ('ASIA', 'AUST'), 
SUBPARTITI ON d2 con2 VALUES ('AMER') 
SUBPARTI TION d2 con3 VALUES (‘AFRICA’) 
SUBPARTI TION d2 con4 VALUES ('EUROPE')), 


PARTITION d3 VALUES LESS THAN ('2012-04-1 00:00:00' 


(SUBPARTITI ON d3 conl VALUES ('ASIA', 'AUST'), 
SUBPARTITI ON d3 con2 VALUES ('AMER') 

SUBPARTI TION d3 con3 VALUES ( AFRICA') 
SUBPARTITION d3 con4 VALUES (' EUROPE']) 


|; 
- -添加 本 地 索引 ， 并 将 其 设置 为 主键 


create unique index pk acc item cur on acc item cur(acc item acc date,area code 


local; 
alter table acc item cur add primary key (acc item acc date,area code 
pk acc item cur 


t 生成 一 些 测试 数据 ， 这 里 老 白 用 了 最 简单 的 方法 ， 虽 然 多 了 几 行 代码 ， 但 是 简单 易 用 
- ` 老 白 坚持 的 原则 是 最 简单 的 就 是 最 好 的 
create sequence seq acc item cache 10000 noorder 
declare 
vdate date 
begin 
vdate:-to date('2012-01-01', ' yyyy- mm- dd ) ; 
for i in 1.. 4000 loop 


using index 


insert into acc item cur values(seq acc item nextval,to char(i),vdate, ASIA’) 
end loop; 
commi t ; 
for i in 1.. 5000 loop 

insert into acc item cur values(seq acc item nextval,to char(i),vdate, ' AMER') 
end loop; 


commit; 
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or i in 1.. 5000 loop 
insert into acc item cur 
values(seg acc item nextval,to char(i),vdate, ' AFRICA') 
end loop; 
commi Ё; 
or i in 1.. 5000 loop 
insert into acc item cur 
values(seq acc item nextval,to char(i),vdate, EUROPE'J; 
end loop; 
commi Ё; 


end; 
| 


declare 
vdate date 
begin 
vdate:-to date('2012-02-05', ' yyyy- mm- dd' ) ; 
for i in 1.. 4000 loop 
insert into acc item cur values(seq acc item nextval,to char(i),vdate, ASIA') 


end loop; 
commi Ё; 
for i in 1.. 5000 loop 
insert into acc item cur values(seq acc item nextval,to char(i),vdate, ' AMER') 
end loop; 
commi Ё; 


or i in 1.. 5000 loop 
insert into acc item cur 
values(seq acc item. nextval,to char(i),vdate, AFRICA ) 
end loop; 
commi Ё; 
or i in 1.. 5000 loop 
insert into acc item cur 
values(seg acc item nextval,to char(i),vdate, ' EUROPE'); 
end loop; 
commi Ё; 


end; 
| 


declare 
vdate date 
begin 
vdate:-to date('2012-03-05' , ' yyyy- mm- dd' ) ; 


for i in 1.. 4000 loop 
insert into acc item cur values(seq acc item nextval,to char(i),vdate, ASIA’) 
end loop; 
commi t ; 
for i in 1.. 5000 loop 
insert into acc item cur values(seq acc item nextval,to char(i),vdate, ' AMER') 
end loop; 
commi t ; 
for i in 1.. 5000 loop 
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insert into acc item cur 
values(seq acc item nextval,to char(i),vdate, ' AFRI СА' ); 
end loop; 
commi t ; 
for i in 1.. 5000 loop 
insert into acc item cur 
values(seg acc item nextval,to char(i),vdate,  EUROPE'); 
end loop; 
commi t ; 


end; 


I 
-创建 中 间 的 交换 表 
CREATE TABLE acc item ex 
( acc item number, 
acc item desc varchar2(20), 
acc date date, 
area code varchar2(6) 
) 
PARTITION BY LIST (area code) 
(PARTITION dl conl VALUES ('ASIA', 'AUST'), 
PARTITION di con2 VALUES ('AMER'), 
PARTITION di con3 VALUES ('AFRI CA') 
PARTITION di con4 VALUES ('EUROPE')); 
create unique index pk acc item ех onacc item ex(acc item acc date,area code) local; 
alter table acc item ex add primary key (acc item асс date,area code) using index 
pk acc item ex; 
-- 创建 历史 表 
CREATE TABLE acc item his 
( acc item number, 
acc item desc varchar2(20), 
acc date date, 
area code varchar2(6) 
) 
PARTITION BY RANGE (acc date) 
SUBPARTI TI ON BY LIST (area code) 
(PARTITION d1 VALUES LESS THAN ('2012-02-1 00:00:00' 
(SUBPARTITI ON 01 conl VALUES ('ASIA', 'AUST'), 


SUBPARTI TION dl con2 VALUES ('AMER') 
SUBPARTI TION dl con3 VALUES ('AFRI CA') 
SUBPARTITION dl con4 VALUES ('EUROPE')), 
PARTITION d2 VALUES LESS THAN ('2012-03-1 00:00:00' 
(SUBPARTITI ON d2 conl VALUES ('ASIA', 'AUST'), 
SUBPARTI TION d2 con2 VALUES ('AMER') 
SUBPARTI TION d2 con3 VALUES ('AFRI CA') 
SUBPARTI TION d2 con4 VALUES ( EUROPE']), 


PARTITION d3 VALUES LESS THAN ('2012-04-1 00:00:00' 


(SUBPARTITI ON d3 conl VALUES ('ASIA', 'AUST'), 
SUBPARTITI ON d3 con2 VALUES ('AMER'), 
SUBPARTITION d3 con3 VALUES ('AFRICA'), 
SUBPARTITION d3 con4 VALUES (' EUROPE']) 
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create unique index pk acc item his on acc item his(acc item acc date,area code) 
local; 

alter table acc item his add primary key (acc itemacc date,area code) using index 
pk acc item his; 

- -进行 表 分 区 交换 

alter table acc item cur exchange partition dl with table acc item ex INCLUDING 
| NDEXES; 


alter table acc item his exchange partition dl with table acc item ex INCLUDING 
INDEXES. WITHOUT VALIDATION ; 


大 家 可 以 看 到 ， 最 后 老 白 用 了 两 次 EXCHANGE 完成 了 表 分 区 的 交换 。 在 进行 分 区 交换 时 ， 
老 白 用 到 了 INCLUDING INDEXES 子 句 ， 这 个 子 句 的 意思 是 包含 所 有 索引 段 的 交换 。 这 样 做 的 
好 处 是 不 需要 重建 本 地 索引 。 这 对 于 数据 量 较 大 的 场合 是 十 分 有 用 的 。 

大 家 可 能 也 注意 到 了 ， 第 二 次 交换 的 语法 有 所 不 同 ， 多 了 WITHOUT VALIDATION 子 句 。 
如 果 我 们 能 够 确定 数据 都 是 正常 的 ， 不 需要 进行 校 验 ， 那么 就 可 以 使 用 这 个 子 句 。 否 则 ，Oracle 
会 在 交换 前 对 ACC. ITEM EX 表 中 的 数据 做 一 次 全 表 扫 描 ， 以 确认 不 存在 不 符合 分 区 规则 的 行 。 
假设 每 个 分 区 的 数据 都 是 亿 万 级 的 ， 那 么 使 用 这 个 子 句 将 十 分 有 效 。 


12.2.2 分 区 表 和 高 水 位 推进 


有 时 ， 系 统 可 能 会 出 现 enq: HW 或 者 eng: FB 这 样 的 等 待 ， 这 种 锁 等 待 是 由 高 水 位 推进 或 者 
格式 化 数据 块 引 起 的 。 在 RAC 环境 下 ， 我 们 可 能 还 会 看 到 大 量 的 gc current grant 相关 的 等 待 事 
件 ， 这 种 等 待 事件 一 般 也 和 高 水 位 推进 有 关 。 

我 们 知道 , 一 张 表 被 创建 后 ,在 第 一 次 插入 数据 的 时 候 , 会 格式 化 一 组 数据 块 ， 数 量 一 般 是 
5 个 ， 在 早期 的 FREELISTS 管理 的 段 空间 上 上， 格式 化 的 数据 块 数量 可 以 通过 参数 
_bump_highwater_mark_count 来 调整 ,但 这 个 参数 在 ASSM 的 段 中 是 没有 作用 的 。 因 为 现在 已 经 
很 少 用 到 MSSM 了 ， 所 以 我 们 主要 讨论 ASSM 下 这 个 问题 的 解决 方案 。 

如 果 某 会 话 要 插入 一 条 记录 , 而 表 中 格式 化 过 的 数据 块 中 已 经 没有 空闲 空间 可 以 容纳 这 条 记 
录 了 ， 这 时 Oracle 就 需要 新 格式 化 一 组 数据 块 ， 格 式 化 数据 块 的 数量 默认 为 S。 在 格式 化 完成 之 
前 ， 所 有 要 搬入 数据 的 会 话 都 会 等 待 HWFB íi (YE RAC 环境 下 ， 会 出 现 gc current grant 方面 的 
等 待 )。 

要 解决 高 水 位 推进 的 问题 , 最 好 的 方法 当然 是 减少 并 发 插入 , 将 单条 数据 插入 改 为 集中 批 处 
理 插入 。 但 是 这 种 修改 需要 从 应 用 架构 方面 去 做 调整 , 系统 上 线 后 较 难 实施 。 如 果 这 条 路 走 不 通 ， 
那么 我 们 就 应 该 反 向 思考 ,既然 无 法 减少 数据 插入 的 并 发 量 , 那么 可 以 考虑 通过 增加 高 水 位 线 的 
数量 来 解决 这 个 问题 , 这 就 和 分 区 表 有 关 了 。 在 前 几 节 大 家 也 了 人 解 到 了 , 分 区 表 中 的 每 个 分 区 实 
际 上 是 一 个 独立 的 段 , 有 自己 的 段 头 和 HWM, 因此 如 果 能 够 将 插入 操作 均匀 分 布 到 多 个 分 区 中 ， 
那么 HW 的 争 用 就 会 得 到 有 效 的 缓解 。 基 于 这 种 考虑 ， 我 们 需要 使 用 HASH 分 区 ， 因 为 HASH 
分 区 能 够 有 效 地 将 序列 连续 产生 的 主键 映射 到 不 同 的 分 区 中 ,在 这 种 情况 下 ,如果 选择 范围 分 区 ， 
就 无 法 起 到 打 散 数据 的 作用 了 。 
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12.2.3 分 区 表 和 RAC 环境 


在 RAC 环境 下 , 分 区 表 的 作用 十 分 特别 。 合理 的 分 区 表 可 以 大 幅 降 低 实例 之 间 的 数据 争 用 ， 
减少 RAC INTERCONNECT 流量 ， 从 而 达到 优化 RAC 系统 整体 性 能 的 作用 。 

假设 我 们 有 一 个 应 用 ， 是 全 省 用 户 使 用 的 。 在 RAC 环境 下 ， 最 简单 的 优化 方法 是 每 个 地 市 
的 用 户 连接 到 自己 独立 的 应 用 服务 器 组 上 ， 而 每 个 地 市 的 服务 器 组 的 连接 池 固 定 连接 到 一 个 实 
例 ， 这 样 如 果 某 些 表 是 按照 地 市 编码 分 区 的 ， 而 应 用 软件 的 SQL 中 又 都 带 有 地 市 编码 的 条 件 ， 
那么 在 一 般 情 况 下 ,， 某 个 分 区 的 数据 就 只 会 被 一 个 地 市 的 用 户 访问 , 而 这 些 用 户 大 多 数 情况 下 也 
只 会 访问 自己 本 地 网 的 数据 。 这 种 分 布 方式 可 以 有 效 减少 多 个 实例 对 同一 数据 块 的 争 用 ,从 而 避 
免 缓 冲 区 融合 带 来 的 性 能 问题 。 目 前 电信 、 移 动 等 运营 商都 采用 这 种 应 用 分 区 的 方式 。 

如 果 不 巧 ,我 们 无 法 按照 上 面 的 方法 进行 分 区 ， 而 目前 某 些 表 上 global buffer busy 等 待 又 十 
分 严重 ， 这 时 应 该 如 何 来 优化 呢 ? 当然 ,加 大 PCTFREE, 减少 BLOCK SIZE 等 都 是 可 用 的 优化 
方法 ,但 是 这 些 方 法 的 效果 都 十 分 有 限 。 如 果 对 这 些 数据 的 访问 主要 以 某 个 字段 的 = 条 件 为 主 ， 
很 少 有 <、> 之 类 的 查询 条 件 存在 〈 即 使 存在 ， 执 行 频率 也 不 是 很 高 ， 对 系统 影响 相对 较 小 )， 而 
这 个 字段 又 正好 是 非 空 字段 ， 那 么 我 们 就 可 以 考虑 根据 该 字段 对 这 张 表 进行 HASH 分 区 ， 这 样 
就 可 以 将 数据 打 散 到 不 同 的 分 区 中 ， 从 而 有 效 地 降低 热 块 冲突 。 

HASH 分 区 并 不 是 万 能 的 ， 它 会 增加 分 区 字段 范围 扫描 的 开销 ,降低 相关 访问 的 效率 。 因 此 
在 设计 分 区 表 时 ， 要 综合 考虑 ， 权 衡 各 种 利 浆 ， 选 择 最 适合 系统 的 解决 方案 。 

在 RAC 环境 中 ， 通 过 表 分 区 来 减少 全 局 热 块 冲突 是 十 分 常用 的 手段 ， 比 如 ，HASH 分 区 可 
以 打 散 数据 ,减少 热 块 冲突 。 另 外 一 种 常用 的 分 区 技术 是 表 分 区 配合 应 用 分 区 ， 从 而 减少 全 局 消 
息 的 数量 。 比 如 , 在 一 个 全 省 集中 的 系统 中 ,每 个 地 市 的 用 户主 要 访问 本 地 区 的 数据 ,， 极 少 访问 
其 他 地 市 或 者 全 省 的 数据 。 在 ВАС 环境 中 ， 如 果 应 用 分 区 采用 了 一 个 地 市 的 用 户 固定 访问 一 个 
实例 这 样 的 策略 ， 并 且 表 分 区 按照 地 市 编码 范围 或 者 LIST 分 区 ， 那 么 就 可 以 限定 某 个 实例 的 客 
户 端 只 会 访问 某 些 特定 分 区 ， 这 样 就 可 以 大 大 降低 全 局 热 块 ， 减 少 gcs/ges 的 流量 。 

在 解决 RAC 中 的 全 局 热 块 冲突 问题 时 ， 选 择 分 区 的 类 别 十 分 重要 。 上 例 中 ， 我 们 可 以 使 用 
LIST 或 者 范围 分 区 ， 当 然 也 可 以 使 用 HASH 分 区 ， 但 后 者 的 效果 就 不 如 前 者 那么 明显 了 。 但 在 
某 些 情况 下 ， 可 能 HASH 分 区 更 为 有 效 。 比 如 ， 应 用 采用 了 负载 均衡 模式 ， 我 们 无 法 将 访问 完 
全 固定 到 某 个 实例 ， 这 种 情况 下 ， 彻 底 打 散 数 据 是 一 个 比较 简单 的 实现 方案 ,通过 HASH 分 区 
就 可 以 完成 这 个 目标 。 

11g 版 本 中 新 增 了 一 类 分 区 ， 即 系统 管理 分 区 。 这 种 分 区 表 没 有 分 区 主键 ， 需 要 程序 显 式 指 
定 分 区 ， 将 数据 插入 到 某 个 分 区 中 。 实 际 上 ， 这 种 分 区 类 似 于 HASH 分 区 ， 不 同 的 是 ， 应 用 开 
发 者 可 以 采用 自 定义 的 方式 将 数据 分 散 插 入 到 某 个 分 区 中 。 比如 有 一 张 日 志 表 用 于 记录 系统 中 的 
一 些 操作 ,数据 插入 后 很 少 被 查询 ， 而 查询 也 往往 依赖 于 某 些 选择 性 较 强 的 查询 关键 字 进 行 。 这 
种 情况 下 , 就 可 以 将 该 日 志 表 设计 为 系统 管理 分 区 表 。 不 同 的 数据 库 实例 插入 数据 到 这 张 表 的 不 
同 分 区 ， 从 而 减少 RAC 实例 间 的 冲突 访问 。 
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12.2.4 分 区 主键 和 分 区 粒度 的 选择 


在 RAC 环境 下 ,合理 使 用 分 区 表 可 以 改善 系统 整体 的 性 能 ,但 不 合理 的 分 区 往往 会 导致 更 
为 严重 的 性 能 问题 。 分 区 主键 和 分 区 粒度 的 选择 是 具有 一 定 技巧 的 ， 如 果 设 计 不 合理 , 分 区 表 就 
无 法 达到 预期 的 效果 。 

在 选择 分 区 主键 时 , 要 考虑 分 区 的 目的 。 如 果 首 要 目的 是 数据 归档 ,那么 第 一 层 分 区 肯定 要 
按照 时 间 字 段 进行 范围 分 区 , 但 如 果 还 有 其 他 的 分 区 目的 ， 可 能 就 需要 设计 子 分 区 ,通过 子 分 区 
来 实现 第 二 目标 。 无 论 采用 哪 种 方式 设计 分 区 , 分 区 主键 是 否 是 系统 查询 语句 中 经 常 使 用 的 过 滤 
条 件 ， 这 一 点 十 分 重要 。 比 如 ， 在 一 张 表 中 ，PHONE_NO 是 一 个 全 局 性 的 号 码 ， 只 能 属于 某 个 
本 地 网 ( 地 市 )， 而 系统 中 有 一 张 根据 本 地 网 编码 分 区 的 分 区 表 。 对 于 这 张 表 ， 我 们 可 以 只 通过 
PHONE_NO=... 来 访问 , 因为 PHONE_NO 具有 全 局 意义 , — PHONE NO 肯定 只 能 属于 一 个 本 
地 网 。 这 种 查询 在 语义 上 没有 任何 问题 , 但 是 由 于 过 滤 条 件 中 没有 本 地 网 代码 ， 所 以 无 法 使 用 分 


区 裁剪 等 功能 。 如 果 在 WHERE 条 件 中 加 上 AND LAN ID =…， 那 么 这 条 SQL 就 能 够 用 到 分 区 
裁剪 功能 了 。 


基于 上 面 的 描述 ， 大 家 可 能 已 经 对 分 区 主键 的 选择 有 所 了 解 了 ， 就 是 要 根据 访问 这 张 表 的 
SQL 中 的 WHERE 条 件 来 进行 设计 。 这 对 于 开发 厂商 来 说 相对 比较 容易 ,而 对 于 那些 对 软件 细节 
一 无 所 知 的 DBA 来 说 ， 可 能 就 很 难 了 。 我 们 应 该 如 何在 黑 盒 中 进行 分 析 呢 ?其实 这 个 工作 难度 
并 不 大 , 只 是 比较 费时 。 通过 分 析 共 享 池 中 的 SQL, 查看 过 滤 条 件 和 连接 条 件 ， 就 可 以 判断 出 哪 
个 分 区 主键 是 比较 合适 的 。 代 码 清单 12-5 是 老 白 常用 的 脚本 ( 这 个 脚本 是 Steven Adams 编写 的 ， 
早期 学 习 Oracle 的 朋友 应 该 比较 熟悉 Steven ,他 的 ixora 网 站 曾经 是 大 多 数 想 学 习 Oracle Internal 
的 DBA 必须 光顾 的 ， 老 白 对 这 个 脚本 进行 了 一 些 修 改 )。 


代码 清单 12-5 


accept OwnerName prompt "Owner Name: ' 
accept TableName prompt "Table Name: ' 


column sql text format a58 word wrapped 


select /*+ ordered use hash(d) use hash(c) */ 


kgl nahsh hash value 
sum(c.kglobt13) disk reads, 
sum(c.kglobt14) logical reads 


sum(c.kglhdexc) executions, 
C.kglnaobj sql text 

from 
sys.x$kglob o, 
sys.x$kgldp d, 
sys.x$kglcursor c 

where 
o.inst id = userenv('Instance') and 
d.inst id = userenv('Instance') and 
c.inst id = userenv('Instance') and 
o.kglnaown = upper(' &OwnerName') and 
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0.kglnaobj = upper('&TableName') and 
d.kglrfhdl = o.kglhdadr and 
c.kglhdadr = d.kglhdadr 

group by 
c.kglnaobj,kglnahsh 

order by 3 

I 


通过 这 个 脚本 ， 可 以 将 访问 某 张 表 的 所 有 SQL 都 查找 出 来 ， 并 根据 逻辑 读 的 数量 进行 排序 。 
( 当然 你 也 可 以 修改 order by 语句， 选择 其 他 的 排序 字段 。 比 如 ，order by 2 是 按照 物理 读 排序 ， 
order by 4 是 按照 执行 次 数 排序 ， 这 些 都 是 最 为 常用 的 排序 方法 。 老 白 一 般 会 根据 执行 次 数 和 逮 
辑 读 进行 排序 分 析 。) 从 后 往 前 分 析 ， 如 果 发 现 绝 大 多 数 查 询 的 过 滤 条 件 中 都 包含 某 个 字段 ， 该 
字段 就 可 以 作为 分 区 关键 字 的 候选 对 象 。 

有 了 候选 对 象 ,， 下面 就 好 办 了 。 如 果 我 们 能 够 确定 该 字段 非 空 ,那么 就 可 以 进一步 确定 其 作 
为 分 区 主键 的 可 行 性 。 如 果 能 够 和 开发 团队 沟通 ,进一步 从 应 用 系统 本 质 的 角度 来 验证 ， 那 就 更 
好 了 。 明 确 了 分 区 主键 ， 下 一 步 就 要 明确 分 区 的 粒度 。 一 个 表 分 区 多 大 才 算 合适 呢 ? 有 人 说 500 
万 条 记录 ， 也 有 人 说 1000 万 条 记录 ， 还 有 人 说 100 万 条 以 内 。 实 际 上 ， 简 单 地 用 记录 数 来 确定 
表 分 区 的 粒度 过 于 轻率 。 表 分 区 是 为 某 个 目的 服务 的 , 因此 如 何 更 好 地 服务 于 目的 才 是 选择 粒度 
的 最 根本 要 素 。 

如 果 分 区 的 目的 是 为 了 便于 维护 ， 那 么 我 们 就 需要 明确 ， 多 大 的 分 区 维护 起 来 才 比 较 便捷 。 
如 果 可 用 于 维护 的 时 间 窗 口 很 得， 所 有 的 分 区 维护 操作 要 求 在 30 分 钟 内 完成 ， 那 么 可 能 500 万 
条 记录 以 下 是 比较 好 的 选择 ， 否 则 我 们 很 难 在 一 个 维护 窗口 内 完成 所 有 的 操作 。 

如 果 分 区 的 目的 是 为 了 便于 归档 , 那么 归档 周期 就 是 分 区 粒度 设计 的 一 个 很 重要 的 因素 。 分 
区 的 跨度 不 能 超过 一 个 归档 周期 ,不 过 一 个 归档 周期 内 可 以 包含 多 个 分 区 。 再 结合 其 他 因素 , 我 
们 就 能 很 容易 地 找到 合适 的 分 区 粒度 。 

如 果 分 区 的 目的 是 为 了 提高 性 能 , 那么 我 们 就 要 考虑 这 张 表 的 范围 扫描 大 多 发 生 在 怎样 的 时 
间 范 围 内 ， 尽 可 能 将 分 区 粒度 和 这 个 扫描 范 围 进 行 对 应 。10 年 前 老 白 曾 碰 到 过 一 个 案例 ， 当 时 
客户 找 了 很 多 人 都 分 析 不 出 问题 的 原因 。 这 个 系统 的 大 多 数 表 是 按照 季度 分 区 的 , 在 每 个 季度 初 
的 5 号 ~10 号 ,系统 的 IO 负载 总 是 特别 高 ， 系 统 性 能 也 非常 差 , 但 过 了 10 号 系统 就 开始 转 好 ， 
15 号 后 就 恢复 正常 了 。 老 白 分 析 后 发 现 ， 这 个 系统 的 范围 扫描 一 般 集 中 在 最 近 半 个 月 内 ， 在 每 
个 季度 最 初 的 几 天 里 ,总 是 要 在 本 季度 和 上 季度 的 分 区 中 扫描 数据 , 这样, 一些 做 分 区 扫描 的 应 
用 的 开销 就 会 比 平时 大 ( 要 扫描 两 个 分 区 ), 而 15 号 后 ,扫描 上 一 个 分 区 的 应 用 减少 ,性 能 就 恢 
复 了 。 于是, 老 白 建议 对 分 区 的 粒度 进行 调整 ,修改 为 每 半 个 月 一 个 分 区 。 这 样 最 坏 的 情况 也 只 
是 需要 对 两 个 半月 的 数据 进行 扫描 ,与 以 前 扫描 3 个 半月 的 数据 相 比 ,改善 了 很 多 。 确实 ,分 区 
调整 完毕 后 ， 每 季度 一 次 的 性 能 危机 就 没有 再 发 生 了 。 
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序列 (sequence ) 是 Oracle 的 序列 号 发 生 器 。 很 多 表 中 必须 存在 唯一 性 的 主键 ， 主 要 用 于 业 
务 关 联 查询 和 防止 重复 。 大 多 数 主键 都 是 单字 段 的 ， 而 且 没 有 具体 的 含义 ， 只 是 用 来 相互 区 分 、 
保证 唯一 性 而 已 ,这 种 字段 的 取 值 就 很 适合 使 用 序列 。 尽 管 序列 被 广泛 使 用 , 但 由 于 其 使 用 方法 
十 分 简单 ， 很 多 人 对 它 都 不 太 在 意 。 实 际 上 , 在 很 多 场合 下 ,序列 的 性 能 也 会 对 系统 产生 很 大 的 
影响 。 在 我 们 设计 应 用 时 ， 合 理 地 设计 序列 也 是 十 分 必要 的 。 


13.1 什么 是 序列 


在 使 用 序列 之 前 , 老 白 都 是 自己 设计 序列 号 发 生 器 的 ,创建 一 张 表 ， 然 后 在 表 中 维护 一 组 记 
录 ， 一 个 典型 的 设计 如 表 13-1 所 示 。 


表 13-1 
ғ R 类 型 说 A 
Id Integer 序列 号 发 生 器 的 编号 ， 唯 一 的 主键 
Val Integer 当前 值 
Desc Varchar2(20) 说 明 
Module Varchar2(20) 使 用 这 个 发 生 器 的 模块 


在 这 种 结构 中 ， 我 们 通过 id 来 访问 对 应 的 序列 号 。 一 般 来 说 ,会 设计 一 个 函数 来 获取 序列 
号 ， 首 先 通过 select ... From … For update 来 锁定 这 条 记录 ， 然 后 将 序列 号 的 Val 增加 1。 实际 上 ， 
Oracle 的 序列 也 是 通过 类 似 的 机 制 来 实现 的 。 大 家 可 以 通过 10046 trace 很 方便 地 看 到 序列 的 创建 
过 程 。 这 个 过 程 十 分 简单 ， 下 面 老 白 将 通过 一 个 示例 来 展示 。 

比如 ， 在 SYSTEM 用 户 下 执行 : 

Create sequence seq test cache 100 noorder; 


首先 检查 该 用 户 下 的 Object 是否 存在 重 名 : 


select obj #,type#, ctime, mtime,stime,status,dataobj #,flags,oid$, sparel, spare2 from 
obj $ where owner #=:1 and name=:2 and namespace=:3 and remoteowner is null and li nkname 
is null and subname is null 
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然后 


如 果 没 有 重 名 的 ， 系 统 就 会 继续 ， 并 通过 obj$ 中 的 隐 含 行 (_NEXT_OJBECT) 获 取 到 obj#, 
进行 操作 : 


select increment$, minvalue, maxvalue, cycle#, order$,cache,highwater,audit$š,flags from 
seq$ where obj #=: 1 


通过 上 面 的 SQL， 可 以 确认 该 obj# 在 seq$ 中 不 存在 ， 于 是 就 插入 一 条 新 的 记录 : 


insert into seq$ ( obj#, increment$, minvalue, maxvalue,cycle# 
order$,cache, highwater,audit$,flags)values(:1,:2,:3,:4,:5,:6,:1,:8,:9,:10) 


当然 ， 生 成 了 seq$ 的 数据 后 ， 还 要 创建 obj$ 的 数据 ， 和 否则 就 会 出 现 数据 字典 不 一 致 


insert into obj$ ( owner# name, namespace, obj#, type# сіі ме, міі те, stime, status 
remoteowner, linkname, subname, ML flags, oid$, sparel, spare2) values 
(51,:12,:13,;:14,:15,10,:7,:9,:9,:10,:11,112;: 13;: 14, 1 15, 1: 16,: 1T) 


在 使 用 序列 时 ， 第 一 次 访问 会 将 序列 的 信息 从 seq$ 中 查 出 ， 存 放 在 内 存 中 : 


PARSING I N CURSOR #1 1 еп=102 depzluidz0 oct =3 |i d=0 ti m=1303870556391017 hv=3967354608 
ad='68acc64c' 
select increment$, minvalue, maxval ue, cycle#, order$, cache, highwater, audit$, flags from 
seq$ where obj #=:1 
END OF STMT 
PARSE #1: c=0, e=22, р=0, сг =0, cu=0, mis=0,r=0, dep=1, og=4, ti m=1303870556391012 
BINDS #1: 
kkscoacd 
Bi nd £0 
oacdty=02 mxl =22(22) mxlcz00 mal =00 5с1 =00 pre=00 
oacflg=08 fl2=0001 frm=00 csi=00 sizz24 off =0 
kxsbbbfpzb72a4388 bln=22 avl=04 flg=05 
val uez72384 


第 一 次 访问 序列 是 比较 特殊 的 , 会 马上 修改 seq$ 中 的 数据 , 而 随后 , 序列 号 是 在 共享 池 中 进 


行 分 配 的 , 不 需要 每 次 都 去 访问 ssq$ 了 ， 只 有 CACHE 耗 尽 ， 才 会 再 次 update seq$, 将 highwater 
的 值 加 大 : 


老 白 
访问 
机 制 


13. 


PARSI NG IN CURSOR #1 | еп=129 dep=1 ui d=0 oct =6 |i d=0 tim=1303870556392458 hv=2635489469 
ad='689bdee4' 

update seq$ set increment$ =:2, minvalue=:3, maxvalue=:4, cycle#=:5, order$=:6, 
cache=:7 ,highwaterz:8, audit$=:9,flags=:10 where obj #=:1 

END OF STMT 


由 于 存在 CACHE, 序列 机 制 比 老 白 早期 自己 维护 的 序列 号 发 生 需 的 效率 要 高 很 多 。 实 际 上 ， 
后 来 也 优化 了 序列 号 发 生 器 , 采用 了 类 似 序列 的 机 制 , 在 共享 内 存 中 维护 一 个 缓冲 区 ,并 发 
的 进程 通过 信号 灯 来 进行 同步 。 序 列 确 实 很 简单 ， 只 要 是 合格 的 架构 师 , 就 能 设计 出 类 似 的 


o 


2 序列 的 使 用 和 优化 
序列 号 发 生 器 包含 seq$ 基 表 和 一 个 缓冲 机 制 , 每 次 访问 seq$ 基 表 都 会 分 配 一 组 缓冲 , 缓冲 用 
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完 之 前 不 会 再 去 访问 seq$ 基 表 。 这 一 点 大 家 可 以 通过 10046 TRACE 来 验证 。 正 因 如 此 ， 序 列 才 
会 在 数据 库 实例 重启 后 产生 跳 号 现象 。 如 果 我 们 的 应 用 不 允许 跳 号 产生 , 那么 就 只 能 通过 将 序列 
设置 为 NOCACHE 来 解决 了 。 根 据 这 一 点 ， 大 家 可 能 很 快 就 会 想到 ， 在 实际 应 用 中 ， 如 果 我 们 
为 序列 设置 较 大 的 CACHE， 就 能 减少 访问 seq$ 基 表 的 次 数 ， 从 而 提高 序列 的 访问 效率 。 表 13-2 
是 老 白 在 一 个 项 目 中 进行 的 测试 。 


表 13-2 
CACHE 并 发 数量 执行 次 数 测试 时 间 (毫秒 ) 平均 每 次 执行 时 间 
2 8 200001 942122 4.7 
100 8 200001 73282 0.366 
1000 8 200001 48250 0.241 
5000 8 200001 47129 0.236 
20000 8 200001 43299 0.216 


从 结果 来 看 , CACHE № 2 提高 到 100, 序列 的 访问 性 能 提升 了 10 多 倍 ; 从 100 提升 到 1000, 
性 能 提升 了 近 一 半 ; 而 从 1000 到 20000， 性 能 提升 的 幅度 就 很 有 限 了 。 从 实验 数据 可 以 看 出 ， 
设置 较 大 的 CACHE 能 够 有 效 地 提升 序列 访问 性 能 。 

除了 CACHE 这 个 属性 外 ， 序 列 还 包含 一 个 和 性 能 关系 极 大 的 属性 ORDER ， 其 含义 是 每 次 
通过 .nextval 获取 序列 的 下 一 个 值 时 是 否 排序 。 如 果 我 们 设 定 某 个 序列 是 有 序 的 ， 那 么 每 次 申请 
nextval 时 , 根据 提出 申请 的 时 间 , 产生 的 序列 值 是 严格 排序 的 , 而 无 序 则 没有 这 个 限制 ORDER 
属性 要 求 序列 中 存在 一 种 完全 串 行 的 机 制 , 每 次 只 能 分 配 一 个 序列 号 , 否则 就 无 法 实现 严格 排序 。 
ORDER 属性 是 和 业务 相关 的 ， 如 果 业 务 要 求 序列 号 是 严格 排序 的 ， 那 么 就 必须 使 用 ORDER Ж 
PE; 但 如 果 序 列 号 只 是 用 作 主 键 ， 顺序 是 无 所 谓 的 ， 那么 NOORDER 就 是 最 好 的 选择 。 

在 RAC EEE, ORDER 属性 会 带 来 很 严重 的 性 能 问题 ， 因 为 Oracle 要 保证 整个 RAC 范围 
内 序列 号 的 产生 都 是 按 顺 序 的 。RDBMS 必须 在 RAC 环境 中 建立 一 种 串 行 机 制 ， 来 协调 序列 号 
的 产生 ， 这 种 需求 会 大 大 降低 序列 号 CACHE 的 作用 。 因 为 序列 号 发 生 需 每 次 申请 一 组 连续 的 号 
码 ， 另 外 一 个 实例 的 序列 号 发 生 器 也 会 申请 一 组 连续 的 号 码 ,这 两 组 号 码 不 会 重复 交叉 ,并 且 是 
有 先后 顺序 的 。 序 列 号 只 能 按 组 使 用 ， 开 始 时 ， 所 有 的 序列 号 申请 都 从 较 小 一 组 的 CACHE 中 进 
行 分 配 ， 这 个 CACHE 分 配 完 了 ， 再 申请 下 一 组 ， 而 这 一 组 的 最 小 值 大 于 另外 一 个 实例 缓冲 中 的 
最 大 值 。 因 此 接 下 来 的 所 有 申请 都 从 另外 一 个 实例 中 分 配 ， 如 此 循环 。 

从 这 个 角度 来 看 ， 使 用 ORDER 属性 的 代价 是 很 大 的 ， 因 此 在 一 般 的 情况 下 ， 不 建议 设置 
ORDER 属性 , 特别 是 在 RAC 环境 下 。 幸 运 的 是 , NOORDER 是 默认 的 设置 , 因此 在 绝 大 多 数 开 
发 人 员 和 DBA 不 知情 的 情况 下 ， 系 统 已 经 使 用 了 性 能 较 好 的 选项 。 

总 的 来 说 ， 序 列 号 是 十 分 简单 的 ， 只 要 设置 较 大 的 CACHE ( 在 一 些 大 型 的 系统 中 ， 可 能 需 
要 设置 1000， 甚 至 5000 )， 并 尽 可 能 使 用 NOORDER 选项 ， 就 不 会 出 现 太 大 的 问题 。 不 过 也 有 
一 些 系统 ， 即 使 设置 了 很 大 的 CACHE , 也 使 用 了 NOORDER 选项 ,还 是 会 存在 十 分 严重 的 序列 
冲突 。 这 种 情况 下 ， 我 们 可 以 考虑 为 应 用 设置 多 个 序列 ， 这 样 ， 应 用 就 可 以 根据 某 种 分 区 规则 , 
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访问 不 同 的 序列 号 发 生 器 来 产生 序列 号 ,然后 再 在 主键 中 拼 人 不 同 的 分 区 标识 , 来 实现 主键 的 唯 
一 性 。 比 如 ， 将 应 用 分 为 三 个 区 A、B、C, 通过 A、B 、C 这 三 个 字母 和 序列 号 拼接 形成 完整 尼 
主键 ， 如 A0012345、B0023456 等 。 相 关 示 例如 下 所 示 : 


SELECT 'A'||TO_CHAR(SEQ1. NEXTVAL,'099999999') FROM DUAL; 
SELECT 'B'||TO_ CHAR(SEQ2. NEXTVAL, '099999999') FROM DUAL; 
SELECT 'C'||TO CHAR(SEQ3. NEXTVAL, '099999999') FROM DUAL; 


分 析 思 路 篇 


思路 是 分 析 问 题 过 程 中 最 为 关键 的 要 素 ， 如 果 没 有 思路 ， 那 么 我 们 就 只 能 漫 无 目的 地 猜想 ， 
无 法 将 焦点 集中 在 关键 的 地 方 。 这 会 导致 问题 定位 时 间 长 ， 解 决 效率 低下 ， 其 至 出 现 治 标 不 治 
本 的 现象 。 

很 多 DBA 都 有 这 样 的 感觉 ， 开 始 的 时 候 好 像 一 直 在 黑暗 中 摸索 ， 突 然 的 灵感 或 者 某 个 人 的 
指点 ， 就 会 让 他 茅 塞 顿 开 ， 很 快 找到 问题 的 关键 ， 从 而 打开 解决 问题 之 门 。 

我 们 如 何 捕获 这 转瞬 即 逝 的 灵感 呢 ? 不 断 地 学 习 当 然 是 很 重要 的 ， 但 更 为 关键 的 是 理解 
Oracle 的 基本 原理 ， 每 次 分 析 问 题 时 都 能 够 抓 住 重点 ， 尽 快 找到 解决 问题 的 最 佳 途径 。 

但 我 们 不 可 能 每 次 都 很 幸运 地 抓 住 问题 的 要 点 ， 这 种 情况 下 ， 建 立 自己 的 预案 体系 就 十 分 
重要 了 。 后 续 章 节 中 的 一 些 内 容 可 以 作为 DBA £r) Pr BS US 00226. 


DBA 往往 面 对 的 是 一 个 十 分 复杂 的 系统 ， 涉 及 面 非常 广泛 ， 相 关 技 术 细 节 也 比较 复杂 。 如 
何在 纷 杂 的 情况 下 尽 可 能 避免 风险 , 并 快速 解决 问题 呢 ? 本 章 我 们 将 从 以 下 几 个 方面 来 讨论 这 个 
问题 。 

第 一 ， 当 面 对 看 上 去 十 分 复杂 的 情况 时 , 应 该 把 握 好 问题 的 本 质 。 从 纷繁 的 表象 中 发 现 问题 
的 本 质 是 十 分 困难 的 事情 , 这 和 DBA 的 能 力 与 知识 结构 有 很 大 的 关系 。 男 外 一 方面 ，DBA Т. 
作 态 度 也 对 问题 处 理 结果 影响 很 大 。14.1 节 “ 如 何 抓 住 蝴蝶 效应 中 的 那 只 蝴蝶 ”通过 一 个 案例 阐 
述 了 如 何在 纷繁 的 表象 下 凭借 细致 的 工作 , 最 终 找到 问题 的 本 源 。 要 想 抓 住 那 只 扇 动 翅膀 的 蝴蝶 ， 
需要 的 不 仅仅 是 技术 ， 更 重要 的 是 责任 心 。 因 此 ， 分 析 问 题 时 ， 只 有 责任 心 强 的 DBA 才 会 打破 
砂锅 问 到 底 ， 最 终 发 现 问题 的 本 质 。 

第 二 ,如 果 对 Oracle 的 本 质 缺 乏 了 解 , 那么 即使 再 有 责任 心 , 也 无 法 抓 住 问 题 的 本 质 ， 因 为 

你 根本 不 知道 某 个 表象 后 面 隐 含 的 Oracle 基本 概念 。 因 此 为 了 能 够 提高 分 析 和 处 理 问题 的 能 
我 们 必须 加 强 自 己 对 Oracle 基础 概念 的 认 知 ， 只 有 了 解 了 Oracle 的 基本 原理 ， 才 能 更 好 地 分 析 
问题 。 
第 三 , 经 验 的 积累 。 如 果 一 个 问题 是 你 以 前 见 过 的 , 或 是 能 在 你 的 知识 库 或 者 Metalink 上 找 
到 的 ， 那 么 这 个 问题 的 分 析 过 程 会 大 大 缩短 ， 投 入 的 成 本 也 会 小 得 多 。 很 多 DBA 都 不 注意 日 常 
的 知识 积累 ,总 是 把 发 生 过 很 多 次 的 问题 当 作 新 问题 来 处 理 , 只 有 分 析 到 后 期 才 突 然 发 现 这 个 问 
题 以 前 好 像 磁 到 过 , 但 是 在 查找 以 往 的 文档 时 , 又 找 不 到 相关 的 信息 , 于 是 只 好 重新 再 处 理 一 遍 ， 
这 样 就 大 大 增加 了 工作 量 。 其 实 ， 积 累 知 识 库 是 DBA 日 党 工作 中 十 分 重要 的 一 部 分 ， 如 果 每 次 
处 理 问题 后 都 能 够 认真 总 结 , 并 且 梳 理 处 理 的 过 程 ， 检 讨 可 以 改进 的 地 方 , 那么 时 间 长 了 ， 就 能 
够 积累 大 量 的 案例 和 处 理 预案 ， 从 而 提高 处 理 问题 的 能 力 。 在 这 方面 ， 老 白 的 建议 是 写 博 客 , 这 
样 既 能 够 及 时 总 结 经 验 , 又 能 够 锻炼 思维 的 周密 性 ,还 能 够 学 习 一 些 之 前 自己 模棱两可 的 知识 ( ZE 
网 络 上 发 布 文章 ， 总 不 能 错误 连篇 ， 令 人 汗颜 吧 ? )， 时 间 长 了 ， 也 许 还 能 成 就 一 个 网 络 名 人 。 

第 四 ,分析 问题 的 成 本 。 对 于 任何 一 个 问题 ， 如 果 不 计 成 本 地 去 分 析 , 那么 找到 问题 根本 原 
因 的 概率 还 是 很 高 的 , 但 并 不 是 所 有 的 问题 都 值得 这 样 做 。 只 有 那些 已 经 或 者 可 能 对 系统 产生 较 

影响 的 问题 才 值得 投入 较 大 的 成 本 去 分 析 。 有 限 的 资金 要 用 到 最 关键 的 地 方 ， 否 则 DBA 就 会 
陷 人 一 个 又 一 个 六 团 之 中 ， 无 法 正常 管理 和 维护 系统 了 。 
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14.1 


如 何 抓 住 蝴 蝶 效 应 中 的 那 只 蝴蝶 


南美 从 林 中 的 一 上 
DBA 在 日 常 工作 中 也 经 常会 面临 类 似 的 问题 


而 仅仅 抓 住 了 莫斯科 上 空 的 乌云 。 
老 日 在 写 这 本 书 时 碰 到 了 
然 出 现 了 故障 ， 服 务 无 法 响应 ,新 会 


只 蝴蝶 扁 动 翅膀 ,可 能 导致 葛 
， 我 们 只 从 故障 的 表象 上 分 析 和 处 理 问 题 ， 
措施 仅仅 针对 一 些 表 象 , 就 没有 找到 问题 的 关键 。 


一 个 案例 ， 写 出 来 和 大 家 分 享 。 客 户 的 一 套 系 统 
话 连 不 上 去 。 


斯 科 下 大 雪 , 这 说 明了 大 和 气 系统 的 复杂 性 。 而 
采取 的 
也 就 是 说 , 我 们 并 没有 抓 到 扇 翅 膀 的 那 只 蝴蝶 ， 


下 午 1 点 多 时 ， 突 


最 后 杀 掉 了 大 量 的 会 话 ， 才 恢复 正常 。 客 户 很 


想 知 道 问 题 的 原因 ， 找 到 我 时 已 经 是 下 午 4 点 多 了 。 出 现 故障 的 时 段 有 大 量 如 下 所 示 的 信息 : 


Mon Apr 11 12:52:24 2011 
Errors in file /oracle/app/oracle/admi n/ 


est2/udump/test22 ora 10410.trc: 


ORA- 00603: ORACLE server session terminated by fatal error 

ORA- 27544: Failed to map memory region for export 

ORA- 27300: OS system dependent operation:bind failed with status: 227 
ORA- 27301: OS failure message: Can't assign requested address 

ORA- 27302: failure occurred at: sskgxpcre3 

Mon Apr 11 12:55:01 2011 

Errors in file /oracle/app/oracle/admin/test2/udump/test22 ora 13426.trc: 
ORA-00603: ORACLE server session terminated by fatal error 

ORA- 27544: Failed to map memory region for export 

ORA-27300: OS system dependent operation:bind failed with status: 227 
ORA- 27301: OS failure message: Can't assign requested address 

ORA- 27302: failure occurred at: sskgxpcre3 

Mon Apr 11 12:55:25 2011 

Errors in file /oracle/app/oracle/admin/test2/udump/test22 ora 13934.trc: 
ОКА- 00603: ORACLE server session terminated by fatal error 

ORA- 27544: Failed to map memory region for export 

ORA- 27300: OS system dependent operation: bind failed with status: 227 
ORA- 27301: OS failure message: Can't assign requested address 

ORA- 27302: failure occurred at: sskgxpcre3 

Mon Apr 11 12:55:25 2011 

Errors in file /oracle/app/oracle/admin/test2/udump/test22 ora 13936.trc: 
ORA-00603: ORACLE server session terminated by fatal error 

ORA- 27504: IPC error creating OSD contex 

ORA- 27300: OS system dependent operation: bind failed with status: 227 
ORA- 27301: OS failure message: Can't assign requested address 

ORA- 27302: failure occurred at: sskgxpcre3 

Mon Apr 11 12:55:25 2011 

Errors in file /oracle/app/oracle/admin/test2/udump/test22 ora 13938.trc: 
ORA-00603: ORACLE server session terminated by fatal error 

ORA- 27504: IPC error creating OSD contex 

ORA- 27300: OS system dependent operation: bind failed with status: 227 
ORA- 27301: OS failure message: Can't assign requested address 

ORA- 27302: failure occurred at: sskgxpcre3 

Mon Apr 11 12:56:00 2011 


Thread 2 advanced to log sequence 2945 ( 
Current log# 4 seq# 2945 mem# 0: /redo 

Mon Apr 11 12:56:01 2011 

Errors in file /oracle/app/oracle/admi n/ 


LGWR switch) 
og/test2/redo04.log 


est2/udump/test22 ora 14554.trc: 
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ORA- 00603: ORACLE server session terminated by fatal error 
ORA- 27544: Failed to map memory region for export 
ORA- 27300: OS system dependent operation:bind failed with status: 227 


同时 还 存在 一 些 类 似 的 ORA-27XXX 错误 : 


Mon Apr 11 12:56:33 2011 

Errors in file /oracle/app/oracle/admin/test2/ udump/test22 ora 22957.trc: 
ОКА- 27509: IPC error receiving a message 

ORA- 27300: OS system dependent operation:recvmsg failed with status: 216 
ORA- 27301: OS failure message: Socket operation on non-socket 

ORA- 27302: failure occurred at: sskgxprcvl 

Mon Apr 11 12:56:33 2011 

Errors in file /oracle/app/oracle/admin/test2/udump/test22 ora 25431.trc: 
ORA- 27509: IPC error receiving a message 

ORA- 27300: OS system dependent operation:recvmsg failed with status: 216 
ORA- 27301: OS failure message: Socket operation on non-socket 

ORA- 27302: failure occurred at: sskgxprcvl 

Mon Apr 11 12:57:24 2011 


根据 ORA-27300: OS system dependent operation:recvmsg failed with status: 216 的 错误 描述 ， 
现场 工程 师 认 为 这 是 bug 6689903 导致 的 ,建议 关闭 NUMA, 客户 准备 晚上 实施 此 操作 ， 想 听 听 
我 的 建议 。 我 觉得 关闭 NUMA 是 一 个 很 重要 的 操作 ， 应 该 十 分 谨慎 ， 所 以 先 要 搞 清 楚 到 底 是 什 
么 导致 了 今天 的 问题 。 从 ORA-27300 来 看 , 这 是 由 于 某 种 OS 资源 不 足 导 致 的 。 因 此 我 们 首先 要 
从 错误 信息 人 手 ， 分 析 HP-UX 的 ERRNO=227、ERRNO=216 这 两 条 错误 信息 ， 查 阅 HP-UX 的 
errno.h 文件 : 


# define ENOTSOCK 216 |* Socket operation on non-socket */ 
* define EADDRNOTAVAIL 221 |* Can't assign requested address */ 


216 错误 表示 在 非 Socket 上 进行 了 Socket 操作 ，227 表示 无 法 分 配 地 址 。Oracle 官方 对 bug 
6689903 的 解释 是 ， 使 用 了 NUMA Ja, Oracle 存在 一 个 Bug ， 导 致 一 个 会 话 使 用 了 大 量 的 UDP 
端口 ， 造 成 UDP 端口 不 足 ， 可 以 通过 更 新 补丁 或 者 关闭 NUMA 来 解决 这 个 问题 。 由 于 UDP 端 
口 耗 尽 也 可 能 导致 ERRNO=227 错误 ， 因 此 可 以 初步 判定 就 是 UDP 端口 耗 尽 导致 了 问题 。 在 这 
种 情况 下 ， 更 新 PATCH 6689903 只 能 解决 过 多 UDP 端口 被 一 个 会 话 消耗 的 问题 ， 并 不 一 定 能 解 
决 所 有 的 问题 ， 当 系统 负载 进一步 加 大 时 ( 系统 设置 的 PROCESSES=4500， 而 发 生 故 障 时 会 话 
数 无 法 突破 1600 )， 可 能 还 会 出 现 问题 。 而 关闭 NUMA 虽然 可 以 减少 UDP 端口 的 使 用 , 但 是 会 
降低 系统 的 性 能 ， 无 法 充分 发 挥 大 型 SMP 系统 的 架构 优势 ， 也 是 不 足 取 的 。 因 此 较 好 的 解决 方 
案 是 先 更 新 PATCH 6689903, 避免 Bug 过 多 消耗 UDP 端口 , 另外 调整 UDP 端口 的 范围 ,从 而 使 
OS 提供 更 多 的 端口 ， 可 通过 下 列 命令 完成 此 操作 : 

oracle@test22:/usr/include/sys$ ndd -get /dev/udp udp largest anon port 

65535 


oracle@test22:/usr/include/sys$ ndd -get /dev/udp udp smallest anon port 
49152 


我 们 看 到 系统 的 UDP 端口 使 用 了 默认 值 ， 通 过 调整 这 两 个 值 ， 使 中 间 的 区 间 变 大 ，OS 就 能 
提供 更 多 的 UDP 端口 号 了 。 问题 分 析 到 这 里 , 已 经 解决 得 差不多 了 。 可 能 大 多 数 DBA 会 觉得 大 
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功 告 成 了 ， 但 老 白 认为 不 然 ， 如 果 说 建议 关闭 NUMA 只 是 看 到 了 下 雪 时 莫斯科 上 空 的 乌云 ， 那 
么 分 析 到 这 里 也 仅仅 是 看 到 了 西伯 利 亚 冷 空气 的 影响 ， 离 那 只 南美 洲 的 蝴蝶 还 有 万 里 之 遥 呢 。 

老 白 当然 会 继续 分 析 下 去 ， 是 什么 原因 导致 UDP 端口 号 被 耗 尽 了 呢 ? 客户 说 ， 平 时 这 个 系 
统 会 话 数 在 1000 出 头 ， 故 障 时 却 达 到 了 1600。 这 很 好 地 解释 了 刚才 的 问题 。 但 是 为 什么 会 话 数 
会 突 增 呢 ? 通过 对 应 用 架构 的 了 解 , 我 们 发 现 这 个 系统 的 大 多 数 应 用 没有 采用 连接 池 ， 而 是 客户 
端 直 连 的 , 当 系 统 处 理 能 力 下 降 时 , 客户 端 与 数据 库 之 间 的 连接 会 增加 , 以 适应 外 部 服务 的 请 求 。 
因此 ， 我 们 可 以 将 焦点 转移 到 使 系统 变 慢 的 情况 。 如 果 在 故障 前 的 某 个 时 段 ， 系 统 突然 变 慢 了 ， 
那么 就 有 可 能 造成 会 话 数 增加 。 会 话 数 增 加 后 ，UDP 端口 配置 过 低 的 问题 就 暴露 出 来 了 。 

那么 接 下 来 就 需要 分 析 系 统 为 什么 会 变 慢 ， 是 在 什么 时 间 变 慢 的 。 通 过 继续 分 析 ALERT 
LOG， 可 以 发 现 第 一 次 报错 的 时 间 是 12 点 41 分 左右 。 


Mon Apr 11 12:38:06 2011 
Thread 2 advanced to log sequence 2940 (LGWR switch) 

Current log# 3 seq# 2940 mem# 0: /redolog/test2/redo03. log 
Mon Apr 11 12:40:58 2011 
Errors in file /oracle/app/oracle/admin/test2/udump/test22 ora 25451.trc: 
ORA- 00603: ORACLE server session terminated by fatal error 
ORA- 27544: Failed to map memory region for export 
ORA- 27300: OS system dependent operation:bind failed with status: 227 
ORA- 27301: OS failure message: Can't assign requested address 
ORA- 27302: failure occurred at: sskgxpcre3 
Mon Apr 11 12:40:59 2011 
Trace dumping is performing id=[cdmp_20110411124059] 


看 来 故障 点 应 该 在 12 点 41 分 之 前 。 于 是 我 们 做 了 一 个 ASH 报告 ,来 查看 12:00 到 12:40 之 
间 系 统 发 生 了 什么 。 为 了 便于 分 析 ， 先 按照 10 分 钟 周 期 生成 4 个 报告 ， 在 前 面 3 个 报告 中 ， 一 
切 正常 ， 而 在 12:30 ~ 12:40 的 报告 中 ， 我 们 发 现 了 一 个 疑点 : 

gcs drm freeze in enter server 24 

在 1 分 钟 内 活跃 会 话 的 采样 中 , 出 现 了 24 次 DRM 等 待 , 平均 等 待 时 间 为 600 毫秒 左右 , 而 
且 这 个 时 间 段 内 的 SQL 执行 次 数 、BUFFER GET 等 指标 明显 低 于 前 面 的 时 段 。 因 此 我 们 可 以 初 
步 断 定 , 这 可 能 是 导致 会 话 数量 突 增 的 一 个 重要 原因 。 但 是 这 个 系统 的 男 外 一 个 节点 跑 的 是 完全 
不 同 的 应 用 ， 而 且 还 没有 投产 ， 为 什么 会 出 现 这 么 多 DRM 呢 ? 通过 LMD, LMON, LMS 等 日 
志 ， 我 们 发 现 ，12:36 ~ 12:38 这 上 段 时 间 里 的 DRM 数量 比 前 面 的 时 段 增 加 了 数 倍 。 于 是 ， 我 们 对 
另外 一 个 节点 上 的 12:30 ~ 12:40 时 间 段 生成 了 一 个 ASH 报告 ， 在 这 里 终于 看 到 了 那 只 美丽 蝴蝶 
的 真面目 。 原 来 在 这 个 时 段 ， 另 外 一 个 节点 上 有 人 用 SQLPLUS 登录 , 访问 了 大 量 的 故障 节点 数 
据 。 而 这 个 操作 导致 了 DRM 事件 增加 ， 短 暂 降 低 了 系统 的 性 能 。 如 果 UDP 端口 号 充足 ， 这 种 
影响 不 会 被 放大 ， 而 仅仅 会 在 12 点 多 钟 业务 不 繁忙 时 段 出 现 短 短 几 分 钟 的 性 能 下 降 ， 很 快 就 会 
平息 。 但 正 是 由 于 UDP 端口 号 不 足 ， 才 放大 了 蝴蝶 扇 动 翅膀 的 动作 。 

抓 住 了 这 只 蝴蝶 ,那么 如 何 解 决 这 个 问题 就 很 明显 了 , 尽 可 能 不 要 出 现 类 似 的 操作 是 肯定 的 。 
不 过 另外 一 个 问题 也 是 需要 我 们 考虑 的 ， 在 这 样 的 一 个 系统 中 ，DRM 其 实 是 不 必要 的 ， 因 为 正 
常情 况 下 ， 两 个 节点 会 跑 自己 的 数据 ， 不 会 交 义 ， 因 此 关闭 DRM 是 一 种 更 理想 的 选择 。 
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大 家 可 能 对 关闭 DRM 这 个 结局 感到 意外 ,但 是 如 果 你 看 过 了 抓 蝴蝶 的 全 过 程 ， 就 会 认为 这 
是 顺理成章 的 了 。 

事情 就 是 这 么 简单 ， 但 是 我 想 大 多 数 人 只 会 走 到 这 个 过 程 中 的 茶 个 步骤 。 这 就 是 DBA 之 间 
的 差距 ， 不 仅仅 是 技术 上 的 ， 更 多 的 是 态度 的 问题 。 
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在 学 习 Oracle 的 过 程 中 ， 我 得 到 一 个 十 分 重要 的 经 验 ， 那 就 是 从 普通 ОВА 成 长 为 专家 、 高 
+, 其 中 非常 重要 的 一 环 就 是 对 基础 概念 的 理解 和 精确 掌握 。 当 然 我 所 说 的 精确 掌握 ， 并 不 是 要 
求 每 个 ОВА 都 把 Oracle 的 源 代 码 读 一 遍 ， 了 解 其 最 底层 的 处 理 模 式 和 方法 。 你 可 以 了 解 得 不 那 
么 深入 ， 但 是 必须 十 分 精准 地 掌握 所 学 的 知识 。 

在 10 多 年 前 ,我 是 靠 经 验 来 处 理 问题 的 ， 那 时 互联 网 还 没有 普及 ,除了 Metalink， 没 有 太 
多 很 好 的 技术 资料 来 源 。 因 此 自己 在 处 理 问题 时 往往 不 得 要 领 ,， 有 时 候 要 绕 很 多 弯路 才能 找到 正 
确 的 方向 。 而 我 现在 处 理 问 题 ， 一 般 都 会 直 奔 主题 ， 很 快 就 能 抓 住 问题 的 关键 。 这 和 10 年 前 那 
一 次 长 达 两 年 的 基础 知识 整理 和 学 习 是 密 不 可 分 的 ， 这 些 经 历 让 我 这 10 年 都 受益 菲 浅 。 

前 几 天 我 又 接 到 了 一 个 morning call。 做 维 保 的 人 最 怕 这 种 凌晨 三 四 点 钟 的 电话 ， 这 种 电话 
一 般 都 意味 着 故障 ， 而 且 往 往 是 大 故障 。 电 话 铃 声 一 响 ， 我 就 从 床上 坐 了 起 来 ， 接 到 电话 后 ， 提 
着 的 心 才 放 了 下 来 。 原 来 这 个 客户 的 监控 平台 报警 , 有 一 个 数据 库 在 用 户 登 录 时 提示 某 个 表 空 间 
ANE, 这 是 一 个 应 用 的 表 空 间 ， 而 不 是 系统 表 空 间 。 发 现 这 个 故障 后 ,客户 没有 直接 通过 扩充 表 
空间 来 解决 问题 , 而 是 想 分 析 一 下 为 什么 会 出 现 这 样 的 故障 。 可 是 他 研究 了 很 长 时 间 也 没有 头绪 ， 
所 以 希望 我 能 帮 他 分 析 一 下 问题 的 原因 。 
事实 上 ， 这 个 客户 处 理 问 题 的 方法 十 分 正确 ， 可 能 很 多 DBA 碰 到 这 类 的 问题 都 会 直接 扩充 
不 足 的 表 空 间 了 事 。 这 种 头痛 医 头 、 脚 痛 医 脚 的 做 法 , 往往 会 让 我 们 失去 很 多 发 现 深层 次 问题 的 
机 会 ， 其 至 留 下 更 为 严重 的 、 灾 难 性 的 隐患 。 

对 于 这 个 问题 ,我 考虑 了 一 下 , 根据 数据 库 登 录 机 制 的 基本 原理 ,这 中 间 应 该 很 少 会 涉及 用 
户 表 空 间 ， 除 非 在 登录 过 程 中 有 客户 化 定制 的 处 理 步骤 。 因 此 查找 问题 的 方向 一 般 只 有 两 个 ,一 
个 是 LOGON 触发 需 或 者 其 他 系统 级 触发 器 ， 另 一 个 是 审计 。 

LOGON 触发 器 是 系统 在 用 户 登 录 时 调用 的 一 个 可 客户 化 定制 的 模块 ， 如 果 客 户 在 LOGON 
触发 器 中 写 入 了 一 些 类 似 于 日 志 的 信息 , 那么 就 有 可 能 出 现 类 似 的 结果 。 一 般 来 说 ,默认 的 审计 
表 不 会 存放 到 应 用 表 空 间 中 , 不 过 有 些 用 户 可 能 会 将 审计 表 从 系统 表 空 间 移 到 用 户 表 空 间 。 不 过 
从 报错 信息 来 看 ， 需 要 扩展 的 表 和 审计 无 关 ， 因 此 可 以 初步 排除 审计 的 问题 。 

基于 上 述 分 析 ， 我 建议 客户 检查 一 下 系统 中 是 否 存在 LOGON fid. Heer SYS IK 
号 后 ,并 没有 发 现 LOGON 触发 避 。 这 让 我 感到 有 点 困惑 ， 根 据 我 对 登录 过 程 的 理解 ， 一 般 来 说 
如 果 排 除了 审计 ， 唯 一 的 可 能 就 是 系统 级 触发 避 。 因 此 , 我 建议 他 再 仔细 检查 一 下 触发 需 ， 我 马 
上 通过 VPN 连 上 去 看 看 。1 分 钟 后 ， 我 的 VPN 拨号 还 没完 成 ， 那 边 的 电话 又 打 过 来 了 ， 问 题 找 
到 了 ， 在 一 个 拥有 SYSDBA 权限 的 普通 用 户 上 ， 发 现 了 一 个 LOGON 触发 器 。 
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这 个 故障 的 处 理 时 间 大 概 在 5 分 钟 到 10 分 钟 之 间 ， 我 的 头 还 昏 告 沉沉 的 ， 问 题 就 解决 了 ， 
倒 在 床上 ，5 分 钟 后 我 又 进入 了 睡眠 状态 。 为 什么 能 这 么 快 定位 到 这 个 问题 呢 ? 这 就 是 基于 对 相 
关 知 识 的 把 握 。 我 不 需要 详细 记 住 LOGON 触发 器 具体 都 做 了 哪些 操作 ， 而 只 需要 知道 登录 过 程 
中 ， 哪 些 步 又 可 能 会 产生 写 操作 ， 哪 些 地 方 是 可 以 个 性 化 定制 的 ， 这 样 就 完全 可 以 解决 问题 了 。 
基于 这 些 知识 ,我们 很 快 就 把 重点 放 在 了 对 触发 器 的 检查 上 , 虽然 中 间 也 犯 了 一 个 小 错误 , 刚 开 
始 仅仅 检查 了 SYS 账号 。 实 际 上 ， 这 只 是 我 在 相关 知识 的 掌握 方面 存在 的 一 点 瑕 病 所 导致 的 。 
在 我 的 印象 里 ，LOGON 触发 天 都 是 在 SYS 账号 下 创建 的 ， 很 少 有 人 在 其 他 用 户 下 创建 LOGON 
触发 吉 。 但 事实 上 ， 只 要 有 相应 权限 的 用 户 都 可 以 创建 系统 级 触发 避 ， 而 且 由 于 LOGON 和 触发 器 
是 系统 级 的 ， 因 此 无 论 在 哪个 用 户 下 创建 的 LOGON 触发 器 ,都 会 被 系统 事件 激发 ， 因 此 在 查找 
触发 器 时 不 能 仅仅 局 限于 SYS 用 户 ， 还 要 考虑 所 有 拥有 DBA, SYSOPER 等 超级 权限 的 用 户 。 
如 果 当 时 使 用 下 面 的 SQL 去 查找 ， 可 能 会 更 快 地 找到 问题 的 原因 : 


SQL>COL TRIGGERING EVENT FORMAT A30 TRUNC 
SQL»SET LINE 132 
SQL»select owner,trigger name,trigger type,triggering event from dba triggers 


OWNER TRI GGER. NAME TRIGGER TYPE TRI GGERI NG EVENT 
S YS SYS_LOGON AFTER EVENT LOGON 
SYSTEM LOGON AUDIT TRIGGER AFTER EVENT LOGON 


从 上 面 的 案例 可 以 看 出 准确 掌握 基础 知识 的 重要 性 , 同时 我 们 也 看 到 了 ， МЕЗ 
Aje. Эр Е, 解决 大 多 数 问 题 ， 都 不 需要 很 深入 地 掌握 内 部 原理 , 仪 仅 掌 握 表 层 的 原理 就 够 
HT o Oracle 数据 库 是 一 个 十 分 庞大 的 软件 体系 ,一 个 问题 可 能 牵涉 的 技术 要 点 非常 多 ， 如 果 没 
有 重点 地 进行 分 析 ， 就 和 撞 大 运 差 不 多 了 ,处 理 问 题 的 效率 会 很 低下 , 找到 问题 根源 的 机 会 也 会 
很 少 。 掌 握 原理 ， 可 以 帮助 我 们 很 快 地 将 焦点 集中 在 重点 区 域 ， 从 而 大 大 提高 解决 问题 的 效率 。 

最 近 这 几 年 我 已 经 很 少 做 实际 操作 了 , 做 的 最 多 的 事情 就 是 接 电话 ， 然 后 提出 建议 。 通 过 几 
次 电话 交流 , 大 多 数 问题 都 能 被 一 线 的 工程 师 解 决 。 这 些 工 程 师 的 实际 动手 能 力 都 不 错 ， 事 情 交 
给 他 们 来 完成 是 没有 任何 问题 的 ， 但 是 他 们 在 碰 到 问题 时 ， 往 往 很 难 快速 地 找到 问题 的 关键 点 ， 
在 这 种 情况 下 ， 通 过 一 些 准 确 的 指导 ,就 可 以 让 他 们 找到 正确 的 方向 ， 从 而 很 快 地 解决 问题 。 有 
时 候 , 我 们 回顾 问题 的 解决 过 程 时 , 经 常会 发 现 , 很 多 一 线 的 工程 师 在 具体 贯彻 我 提出 的 思路 时 ， 
会 进行 很 多 创造 性 的 工作 ， 即 便 我 对 这 个 问题 原理 的 理解 更 准确 、 深 刻 , 但 很 多 问题 如 果 换 成 我 
来 做 ， 处 理 的 结果 可 能 并 没有 他 们 好 。 这 是 因为 他 们 长 期 在 第 一 线 从 事 第 一 手 的 操作 工作 , 在 某 
个 方面 的 具体 操作 层面 上 , 他 们 的 实际 经 验 可 能 比 我 还 要 丰富 。 准 确 把 握 基础 原理 和 丰富 的 实际 
操作 经 验 ， 是 更 好 地 解决 问题 的 两 个 必要 条 件 ， 如 果 这 两 点 结合 得 好 ， 处 理 问题 就 会 事半功倍 。 
在 完成 一 项 工作 时 , 一 个 优秀 的 一 线 操作 人 员 和 一 个 资深 专家 的 组 合 往往 是 最 佳 的 。 很 多 客户 都 
希望 所 有 的 事情 都 能 由 资深 专家 亲自 操 刀 ,其 实 这 不 一 定 是 很 好 的 选择 , 专家 可 能 更 多 的 是 深入 
研究 一 些 原理 性 的 问题 , 实际 操作 能 力 有 可 能 已 经 相对 下 降 了 , 操作 的 效果 可 能 还 不 如 一 线 操作 
人 员 。 

在 这 种 情况 下 ， 最 好 的 方法 是 ， 专 家 指导 完成 操作 手册 ， 由 一 线 操作 人 员 实 施 具 体 的 操作 。 
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在 本 节 开 始 之 前 , 我 先 提 一 个 问题 : 如 果 客 户 的 Oracle 安装 目录 满 了 , udump 下 有 好 多 几 百 
兆 字 节 甚 至 上 千 兆 字 节 的 trace 文件 ， 而 这 个 时 候 ， 客 户 的 存储 上 又 没有 空闲 空间 备份 这 些 文 件 
了 ， 而 且 情 况 十 分 紧急 ,已 经 有 业务 受到 了 影响 ， 需 要 尽快 解决 问题 ， 这 种 情况 下 该 怎么 处 理 ? 

这 个 问题 看 似 十 分 简单 ， 不 过 要 想 让 老 白 打 满 分 也 确实 不 容易 。 我 想 大 多 数 DBA 会 直接 清 
了 udump AKTE, 也 有 一 些 相对 谨慎 的 DBA, 会 先 把 这 些 文件 备份 , 然后 再 删除 udump 目录 ， 
但 因为 本 地 没有 可 用 的 备份 空间 ， 于 是 他 们 会 通过 ftp 将 这 些 文件 先 复制 到 自己 的 电脑 上 。 还 有 
一 些 DBA 处 理 得 更 加 “艺术 ”, 首先 通过 ftp 复制 几 个 不 是 特别 大 的 trace 文件 ,然后 删除 udump 
目录 ， 让 系统 故障 先 消失 ， 再 慢 慢 处 理 那 些 比较 大 的 文件 。 

EX, 如 果 不 将 现场 的 紧急 情况 作为 条 件 , 解决 这 个 问题 的 好 方法 有 很 多 。 但 是 在 很 紧急 的 
情况 下 ,要 采用 最 为 正确 的 方法 确实 很 难 。 老 白 就 碰 到 过 这 样 的 问题 , 而且 差点 犯 了 一 个 低级 的 
错误 ， 幸 亏 多 年 养 成 的 好 习惯 帮 了 忙 ， 否 则 后 果 不 堪 设想 。 

问题 场景 和 我 上 面 的 描述 十 分 相似 。 这 是 一 个 流 复制 的 项 目 ，, 系统 刚刚 上 线 , 我 正在 现场 值 
守 ， 由 于 SDH 线路 问题 以 及 目标 端 APPLY 进程 很 缓慢 ， 所 以 一 直 在 调整 APPLY 进程 的 性 能 。 
这 个 时 候 归 档 目 录 突 然 满 了 , 但 由 于 CAPTURE 的 REQUIRED_CHECKPOINT_SCN 还 没 推进 到 
某 个 点 ， 所 以 目录 下 的 归档 日 志 已 经 无 法 删除 了 。 经 过 检查 ，udump FJ JL T trace 文件 ， 最 
大 的 有 几 千 兆 字 节 , 加 在 一 起 有 七 八 千 兆 字 节 ， 于 是 我 和 客户 商量 了 一 下 , 决定 马上 清 掉 udump 
目录 。 由 于 当时 无 法 归档 ， 业 务 系统 已 经 挂 起 了 ,我 很 紧张 ， 没 怎么 考虑 就 执行 了 rm 命令 。 命 
令 执 行 完 了 ， 用 qf 命令 一 检查 ， 发 现 文 件 系 统 使 用 率 还 是 100%。 当 时 脑子 “ 喻 ”的 一 下 ， 汗 马 
上 顺 着 脖子 流 了 下 来 。 我 突然 想到 一 个 问题 , 在 UNIX 系统 下 ， 如 果 一 个 文件 被 删除 了 , 但 某 个 
进程 打开 这 个 文件 后 没有 关闭 ， 那 么 该 文件 可 能 就 无 法 释放 空间 。 由 于 我 删除 的 是 udump 下 的 
SCPE, 所 以 还 必须 把 相关 的 前 台 进 程 也 杀 掉 。 因 此 我 需要 找到 那 几 个 最 大 文件 的 文件 名 ,根据 文 
件 名 里 的 进程 号 去 杀 掉 相关 进程 。 于 是 我 马上 把 secureCRT 的 屏幕 往 前 翻 ， 去 查找 刚才 1s -1 命 
令 的 结果 。 

屋 漏 偏 着 连夜 十 ， 因 为 翻 得 太 急 ，secureCRT 居然 死 掉 了 ， 拖 动 屏幕 没有 任何 反映 。 由 于 刚 
才 没 有 备份 相关 的 trace 文件 ， 所 以 我 根本 不 知道 那 几 个 比较 大 的 trace 文件 的 文件 名 是 什么 。 重 
新 启动 secureCRT 登录 系统 后 ， 我 发 现 这 套 系 统 没 有 安装 lsof， 也 没有 安装 glance 之 类 的 系统 工 
具 。 看 来 我 磁 到 大 麻烦 了 ， 几 千 个 会 话 ， 不 知道 要 杀 掉 多 少 才能 解决 这 个 问题 ， 如 果 全 部 杀 掉 ， 
那 就 是 大 故障 了 。 当 时 我 很 后 悔 没 有 把 ls 的 信息 记录 下 来 。 这 时 我 突然 想到 , 我 的 secureCRT 应 
该 是 开 了 会 话 日 志 的 , 而 且 是 追加 模式 的 。 于 是 我 通过 secureCRT 找到 了 那个 日 志 以 及 刚才 执行 
15 -1 的 结果 。 杀 掉 几 个 会 话 后 ， 磁 盘 空 间 终 于 释放 了 。 

10 多 年 前 ， 有 一 次 我 在 客户 现场 安装 软件 时 ， 突 然 服 务 器 上 有 文件 被 误 删 了 ， 客 户 认 为 是 
我 干 的 , 但 我 很 肯定 这 与 我 无 关 ， 因 为 我 访问 的 磁盘 都 和 那个 被 误 删 的 文件 不 同 。 但 是 我 没有 任 
何 证 据 能 证 明 自 己 的 清白 ,最 后 的 结果 是 和 客户 吵 了 一 架 ， 客户 向 领导 投诉 了 我 。 从 那 以 后 , 在 
用 户 现场 ,我 一 般 都 会 连 和 客户 的 服务 器 ,并 打开 会 话 跟踪 日 志 ， 每 次 安装 完 secureCRT 后 马上 
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将 其 设置 为 以 添加 方式 自动 打开 日 志 。 这 个 习惯 在 危机 时 曾 多 次 “解救 ”过 我 ,而 且 还 为 我 保留 
了 大 量 案例 处 理 的 原始 资料 ， 这 10 多 年 来 , 已 经 积累 了 差不多 40 GB。 这 些 资料 为 我 后 来 归纳 
知识 、 回 顾 案例 ， 提 供 了 大 量 的 宝贵 信息 。 

老 白 一 直 在 强调 理解 基本 原理 ,并 应 用 到 实践 中 , 但 是 有 些 时 候 , 一 个 操作 涉及 的 知识 面 太 
广 了 ,我 们 可 能 无 法 考虑 得 那么 全 面 ， 总 会 有 一 些 遗 漏 。 这 时 ， 好 习惯 就 显得 尤为 重要 了 。 这 就 
好 像 开 车 一 样 , 老 白 也 喜欢 在 高 速 公 路 上 开 快 车 , 不 过 在 周围 车 比较 多 的 时 候 , 我 会 十 分 注意 车 
距 ， 因 为 我 知道 自己 的 车 在 100 公 里 /小 时 的 速度 下 ， 从 刹车 到 静止 需要 55 米 左 右 的 距离 ， 因 此 
我 会 尽 可 能 和 前 车 保持 50 米 以 上 的 距离 。 所 以 ,保持 好 的 开车 习惯 可 以 在 关键 时 刻 救 你 一 命 ; 
同样 ， 好 的 工作 习惯 ， 也 往往 会 在 关键 时 刻 帮 你 “转危为安 ”。 

在 日 常 工作 中 ，DBA 需要 养 成 的 好 习惯 有 很 多 。 

口 在 去 客户 现场 之 前 ， 要 和 客户 通 一 个 电话 ， 了 解 工 作 的 范围 和 重点 ， 然 后 提前 做 一 些 功 

课 ， 把 与 工作 相关 的 知识 要 点 准备 好 。 每 个 人 的 能 力 都 是 有 限 的 ， 知 识 面 也 都 存在 一 些 
短 板 ， 做 好 充分 的 准备 是 对 客户 负责 ， 也 是 对 自己 负责 。 
а 学 会 倾听 ， 认 真 听取 客户 的 想法 、 客 户 对 工作 的 希望 以 及 客户 对 项 目的 理解 ， 这 对 于 提 
高 客户 的 满意 度 十 分 关键 。 无 论 技 术 多 么 优秀 ， 任 务 完成 得 多 么 出 色 ， 不 合 客户 的 口味 
也 是 没 用 的 。 

о 操作 之 前 , 应 打开 各 种 能 够 记录 操作 过 程 的 日 志 , 比如 secureCRT 的 会 话 日 志 。 正 如 上 述 

案例 中 提 到 的 那样 ， 这 些 日 志 可 以 挽回 重大 损失 ， 有 时 也 可 以 避免 一 些 纠 纷 。 

о 事先 在 自己 的 编辑 器 中 写 好 所 有 的 操作 ， 最 后 再 粘贴 到 虚拟 终端 上 去 执行 。 这 个 习惯 一 
方面 可 以 将 每 次 操作 的 脚本 都 记录 下 来 ， 另 外 一 个 方面 也 可 以 帮助 我 们 在 执行 之 前 审阅 
脚本 ， 最 关键 的 是 ， 可 以 有 效 地 避免 虚拟 终端 上 的 误 操 作 。 

а 碰 到 自己 无 法 把 控 风 险 的 操作 ， 尽 可 能 咨询 一 下 其 他 人 ， 或 者 尽早 将 其 升级 到 二 线 或 三 
线 ， 千 万 不 要 轻易 把 自己 置 于 未 知 的 危险 境地 。 当 我 们 以 团队 方式 工作 时 ， 没 有 必要 一 
个 人 来 承担 所 有 的 风险 ， 只 需要 承担 自己 的 那 部 分 责任 即 可 。 

О 在 离开 客户 现场 前 ， 要 和 相关 负责 人 进行 沟通 ， 说 明 本 次 工作 的 内 容 ， 做 了 什么 事情 ， 

有 什么 遗留 问题 ， 有 什么 后 续 建 议 。 这 样 会 让 客户 感觉 你 很 专业 ， 也 很 尽责 。 

о 完成 一 个 项 目 后 ， 应 尽快 写 一 份 文档 记录 本 次 工作 。 就 我 个 人 而 言 ， 无 论 客户 是 否 需 要 
提交 文档 ， 我 都 会 针对 一 些 有 趣 的 操作 编写 自己 的 文档 。 编 写 过 程 中 ， 我 会 对 本 次 操作 
进行 总 结 ， 也 会 对 自己 做 一 次 评审 ， 看 看 操作 过 程 中 是 否 还 存在 需要 改进 的 问题 。 

这 里 只 列举 了 7 条 , 实际 上 还 有 很 多 没有 列 出 。 其 实 ， 良好 的 习惯 都 是 通过 惨痛 的 教训 换 来 
的 , 每 次 失败 和 故障 都 应 该 成 为 我 们 改进 的 动力 , 记 吃 不 记 打 的 事情 不 应 该 在 一 个 高 度 职业 化 的 
DBA 身上 多 次 发 生 。 


DBA 分 析 思 路 的 探讨 


我 们 在 碰 到 问题 后 该 如 何 去 分 析 ， 应 从 哪些 方面 人 手 去 诊断 和 解决 问题 呢 ? 这 可 能 是 每 个 
DBA 都 想 学 习 的 。 其 实 这 个 问题 并 不 复杂 ， 我 们 可 以 先 抛 开 Oracle 数据 库 ， 来 看 看 普通 问题 的 
分 析 方 法 。 

在 碰 到 问题 时 , 我 们 首先 会 根据 自身 的 经 验 去 分 析 这 个 问题 是 属于 哪 一 类 的 , 接着 会 考虑 在 
这 一 类 问题 上 我 们 具备 哪些 经 验 , 这 些 经 验 是 否 有 助 于 我 们 分 析 问 题 。 如 果 我 们 在 这 类 问题 上 是 
有 经 验 的 , 那么 就 可 以 根据 经 验 进行 思考 和 分 析 ， 直 到 找 出 解决 方案 ; 如 果 我 们 的 经 验 不 足以 解 
决 问题 ， 那 么 可 能 就 会 向 亲 威 、 朋 友 求 助 。 

在 互联 网 时 代 , 我 们 也 可 能 会 考虑 使 用 搜索 引擎 ， 查 找 相同 或 者 类 似 的 案例 。 但 由 于 网 络 上 
的 信息 并 不 一 定 可 靠 , 我 们 在 搜索 时 , 会 花费 大 量 的 时 间 过 滤 人 信息, 判断 信息 的 正确 性 。 使 用 搜 
索引 擎 最 大 的 问题 就 是 搜索 结果 并 不 一 定 正 确 , 因此 进行 必要 的 判断 是 十 分 关键 的 。 如 果 不 加 判 
断 ， 直 接 引 用 ， 可 能 会 带 来 严重 的 后 果 。 

HK, DBA 在 分 析 数 据 库 问 题 时 也 离 不 开 这 些 普 遍 规律 ， 如 果 相 关 问 题 首 次 出 现 ， 可 通过 
Metalink 、 谷 歌 以 及 百度 进行 搜索 ， 或 者 向 高 手电 话 咨询 。 

本 章 的 目的 就 是 将 老 白 这 些 年 来 总 结 的 一 些 分 析 问 题 的 思路 分 享 给 大 家 , 不 过 每 个 DBA 都 
有 自己 的 思考 习惯 ， 因 此 老 白 希 望 大 家 能 够 借鉴 这 些 思路 ， 用 以 补充 自己 的 不 足 ， 但 不 要 生硬 
地 全 盘 照 搬 。 只 有 把 这 些 考 虑 问题 的 方法 和 技巧 完全 融入 到 自己 的 思维 体系 中 ， 本 章 的 内 容 才 
能 发 挥 真 正 的 作用 。 一 味 生 搬 硬 套 ， 不 懂得 消化 吸收 ， 效 果 自 然 不 好 ， 甚 至 还 可 能 导致 十 分 严 
重 的 后 果 。 


15.1 问题 分 析 总 路 线 图 


WIT Oracle 数据 库 , 我 们 处 理 问题 时 ,都 有 一 个 通用 的 路 线 图 。 首 移 要 和 弄 明 白 遇 到 了 什么 
问题 , 问题 的 现状 是 什么 , 然后 根据 现状 分 析 可 能 存在 的 处 理 路 径 , 这 个 问题 是 归 到 哪 一 类 的 ， 
以 前 是 否 碰 到 过 , 是 否 可 以 在 自己 的 能 力 范 围 内 解决 。 根据 这 些 , 我 们 会 采取 相应 的 处 理 措施 。 

作为 DBA， 在 碰 到 问题 时 ， 最 先 要 做 的 事情 同样 也 是 了 解 问题 的 现状 。 如 果 我 们 在 现场 ， 
就 可 以 亲自 去 查看 问题 现状 ， 而 在 其 他 时 候 可 能 只 是 听 别 人 转述 问题 。 这 种 情况 下 ,我 们 接触 到 
的 第 一 手 信息 可 能 并 不 是 问题 的 真正 面目 ， 因 此 不 可 尽 信 ， 需 要 从 中 分 辨 出 真实 的 信息 。 这 时 ， 
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如 果 手 头 有 一 些 抓 取信 息 的 小 脚本 , 那 就 最 好 不 过 了 。 通过 这 些 脚 本 , 我 们 可 以 抓 取 到 最 为 原始 、 
易于 分 析 的 数据 。 由 于 每 个 人 的 工作 习惯 不 同 ， 因 此 这 些 脚 本 的 差别 可 能 会 很 大 。 很 多 ОВА 都 
收集 了 大 量 高 手 或 者 大 师 的 脚本 , 但 是 他 们 并 不 知道 如 何 使 用 这 些 脚本 , 因此 这 些 脚 本 虽然 很 好 ， 
但 是 没有 什么 用 处 。 所 以 说 ,准备 一 些 自己 能 够 使 用 的 脚本 才 是 真正 关键 的 。 经 过 一 段 时 间 的 沉 
iÉ, FA DBA 都 会 积累 一 套 使 用 起 来 得 心 应 手 的 、 适 合 自己 的 脚本 ， 由 于 对 这 些 脚 本 有 十 分 次 
入 的 理解 ， 因 此 通过 这 些 脚本 就 可 以 完成 绝 大 多 数 的 分 析 工 作 。 

不 过 有 些 时 候 , 客户 出 于 安全 考虑 ， 可 能 不 允许 将 脚本 上 传 到 他 们 的 服务 器 ， 因 此 我 们 还 必 
须 掌握 一 些 简单 的 命令 ， 用 于 信息 的 采集 和 分 析 。 一 般 来 说 ， 这 些 命令 必须 简单 易 记 ， 如 果实 在 
记 不 住 ， 也 可 以 记录 在 一 个 文本 文件 里 , 需要 的 时 候 拿 出 来 查看 一 下 ( 也 就 是 说 ， 常 用 命令 不 能 
太 复 杂 ， 起 码 是 可 以 一 边 看 一 边 输入 到 客户 系统 中 的 命令 ， 过 于 复杂 的 SQL 不 适合 作为 初步 分 
析 和 信息 采集 的 工具 )。 

无 论 如 何 , 掌握 第 一 手 准确 资料 是 最 为 关键 的 , 分 析 问 题 的 一 个 最 为 根本 的 前 提 就 是 所 掌握 
的 数据 是 正确 的 ， 否 则 分 析 不 可 能 顺利 进行 。 
现在 我 们 把 讨论 范围 集中 到 Oracle 的 问题 分 析 上 。 如 果 某 个 Oracle 数据 库 出 现 了 问题 ， 那 
么 我 们 该 如 何 分 析 呢 ? 首先 来 看 看 我 们 是 如 何 发 现 问题 的 。 一 般 来 说 , 数据 库 服 务 器 故障 主要 表 
现在 以 下 几 个 方面 : 

口 数据 库 无 法 登录 ; 

a 数据 库 运 行 缓慢 ; 

口 数据 库 出 现 坏 块 ; 

a 访问 数据 库 出 现 报错 ， 无 法 正常 执行 某 些 功 能 ; 
a 数据 库 整 个 挂 起， 无 法 执行 SQL; 

о 某 个 SQL 执行 时 挂 起 ; 

口 CPU 使 用 率 突然 变 大 ， 甚 至 达到 100%; 

a 某 个 业务 功能 突然 变 慢 ; 

口 操作 系统 突然 变 慢 。 

虽然 故障 的 现象 千奇百怪 ， 不 过 总 结 起 来 不 外 乎 以 下 几 种 : 
口 操作 系统 方面 的 故障 ; 

口 数据 库 功 能 性 故障 ; 

口 数据 库 性 能 故障 ; 

О SQL*Net 故障 ; 

a SQL 性 能 故障 。 

由 于 每 个 系统 都 是 不 同 的 ， 所 以 对 于 不 同 的 用 户 , 经 常 要 分 析 的 问题 种 类 也 会 有 所 不 同 , 分 
析 方 法 也 存在 差异 。 因 此 对 于 每 个 DBA 来 说 ， 事 先 制定 好 一 些 分 析 预 案 是 十 分 重要 的 。 通 过 预 
案 分 析 问 题 ， 可 以 大 幅 减 少 误 判 ， 从 而 提高 问题 的 解决 率 。 积 累 分 析 预 案 是 每 个 РВА 在 日 常 学 
J. 工作 中 必须 要 做 的 事情 , 只 有 这 样 ， DBA 的 工作 能 力 才能 不 断 地 提升 。 也许 很 多 DBA 会 说 ， 
我 从 来 没有 积累 过 预案 ,但 是 随 着 工作 时 间 的 增加 , 我 的 工作 能 力也 在 不 断 提升 。 实 际 上 , 我们 
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每 时 每 刻 都 会 碰 到 问题 ， 都 在 分 析 和 解决 问题 ， 每 次 解决 问题 后 ， 我 们 或 多 或 少 都 会 有 些 记忆 ， 
下 一 次 碰 到 类 似 的 问题 时 ,这 些 旧 的 记忆 总 是 能 够 对 我 们 有 所 帮助 。 因 此 , 我 们 在 不 自觉 地 积累 
着 处 理 预案 。 不 过 这 种 积累 预案 的 方式 效率 较 低 ， 而 且 预 案 的 质量 也 不 高 。 如 果 每 次 处 理 问 题 后 
能 够 主动 对 处 理 过 程 进行 提炼 ,并 根据 自己 的 知识 推 而 广 之 , 这 样 形成 的 预案 质量 就 会 大 幅 提 高 。 
下 次 遇 到 类 似 问题 时 ， 处 理 水 平 也 会 有 所 提高 。 

不 过 很 不 幸 的 是 ， 绝 大 多 数 DBA 的 预案 体系 都 不 完备 ， 而 且 其 基本 的 案例 积累 也 不 足以 完 
成 问题 的 分 析 。 在 这 种 情况 下 ， 该 如 何 进行 分 析 呢 ? 
由 于 系统 出 现 的 问题 多 种 多 样 ， 因 此 查看 系统 资源 、 日 志 信 息 是 十 分 重要 的 。 很 多 DBA 在 
分 析 故 障 时 连日 志 都 没 仔细 分 析 ， 就 急 着 根据 问题 现象 去 谷歌 、 百 度 上 搜索 。 BAMA ОВА Т. 
作 经 验 的 增加 , 用 这 种 方法 在 大 多 数 情况 下 也 能 找到 合适 的 解决 方案 , 但 是 存在 的 隐患 同样 也 很 
大 ,经 常会 因为 找到 的 处 理 方法 不 正确 而 导致 问题 无 法 解决 ,更 为 严重 的 是 ,如 果 操 作 过 程 存在 
风险 或 者 不 可 逆 ， 就 有 可 能 导致 严重 的 事故 。 

作为 一 名 DBA， 养 成 查看 日 志 的 习惯 是 十 分 重要 的 ， 因 为 Oracle 的 很 多 问题 都 会 体现 在 日 
志文 件 中 。 这 里 所 说 的 日 志文 件 既 包含 alert log 和 各 类 trace 文件 , 也 包含 操作 系统 和 群集 软件 的 
日 志 。 其 中 ， 操 作 系统 和 群集 软件 的 日 志 是 大 多 数 DBA 可 能 会 忽视 的 ， 但 实际 上 这 些 日 志 十 分 
关键 。 另 外 ，DBA 还 应 了 解 其 维护 的 数据 库 系 统 、 操 作 系统 、 集 群 软件 以 及 与 Oracle 数据 库 相 
关 的 其 他 第 三 方 软件 日 志文 件 的 存放 位 置 以 及 查找 和 分 析 的 方法 。 对 于 系统 故障 、 突 然 变 慢 、 出 
现 坏 块 ers 无 法 正常 启动 等 情况 ， 检 查 操作 系统 日 志 是 十 分 重要 的 。 

除了 检查 日 志 以 外 , 查看 当前 系统 的 资源 使 用 情况 也 十 分 关键 , 很 多 故障 都 是 由 于 系统 资源 
出 现 问题 导致 的 。 因 此 ， 我 们 应 重点 检查 СРО, РИТ, ГО 和 网 络 的 情况 。 以 前 老 白 曾 磁 到 过 一 
个 问题 , 在 一 套 由 3 个 异地 节点 组 成 的 三 向 STREAMS 复制 环境 中 , 主 生 产 节 点 每 天 大 概 有 3000 
万 条 记录 要 同步 到 华东 和 华中 两 个 节点 ,华东 、 华 中 节点 每 天 大 约 各 有 200 万 条 左右 的 记录 要 同 
步 到 其 他 节点 。 有 一 次 ， 主 节点 向 华中 同步 的 数据 延 时 突然 变 得 十 分 严重 ， 而 且 在 不 断 增 大 , 已 
经 达到 几 个 小 时 。 经 过 检查 发 现 ，STREAMS 环境 正常 ， 而 捕获 进程 经 常 出 现 由 于 UNBROWSE 
消息 数量 过 多 而 导致 的 流 控 ， 在 华中 节点 的 APPLY 端 ，APPLY 进程 大 多 数 时 间 都 比较 空闲 。 通 
过 strmmon 工具 分 析 发 现 ， 华 中 节点 的 网 络 传输 速率 只 有 300 Kbit/s 左右 ， 而 一 般 情况 下 ， 如 果 
出 现 较为 严重 的 延 时 ， 网 络 传输 流量 的 平均 值 不 应 该 低 于 600 Kbit/s。 于 是 我 们 将 这 种 情况 初步 
定位 为 PROPAGATION 进程 方面 的 问题 。 在 调整 了 一 系列 参数 并 重启 该 进程 后 ， 问 题 仍然 没有 
解决 ， 那 么 下 一 个 怀疑 的 对 象 就 是 网 络 本 身 了 。 主 系统 到 华中 节点 的 网 络 采用 了 电信 的 SDH, 
客户 租用 了 一 条 15 Mbit/s 的 光纤 通道 。 首 先 我 们 检查 了 操作 系统 的 日 志 ， 没 有 发 现 网 络 报错 的 
现象 ， 于 是 又 通过 netstat 命令 检查 网 络 的 状况 ， 也 没有 发 现 问题 。 接 下 来 通过 ping 命令 发 现 大 
小 包 的 速度 都 在 十 几 毫 秒 , 属于 正常 范围 。 于 是 我 们 联系 了 运营 商 , 运营 商检 查 发 现 ,这 条 专线 
没有 问题 ， 能 够 达到 15 Mbits 的 传输 峰值 。 既 然 运营 商都 已 经 确认 网 络 没 有 问题 ， 好 像 下 一 步 
就 没有 什么 可 用 的 方法 了 。 不 过 我 们 好 像 还 遗忘 了 一 个 最 为 简单 的 方法 ,于 是 我 们 停止 了 传播 进 
TE, 然后 使 用 SFTP 去 复制 一 个 几 千 兆 字 节 的 大 文件 , 在 传输 过 程 中 我 们 发 现 网 络 确实 存在 问题 ， 
理论 上 SFTP 的 传输 速度 应 该 能 够 达到 1 Mbit/s 以 上 ， 而 实际 测试 时 ， 只 能 达到 400 Kbit/s ТЖ 
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度 。 既 然 运 营 商 能 够 确保 15 Mbit/s 的 传输 带宽 ( 也 就 是 接近 2MB/s， 运 营 商 的 带宽 单位 是 bit ), 
而 实际 的 网 络 传输 速度 只 能 达到 该 值 的 1/50, 那么 肯定 有 其 他 的 应 用 在 使 用 网 络 。 由 于 缺乏 足够 
的 网 络 监控 工具 , 我 们 只 能 对 使 用 本 网 络 的 系统 进行 排查 。 经 过 排查 发 现 , 总 部 和 华中 节点 间 的 
一 套 电话 视频 会 议 系统 的 备用 线路 可 以 使 用 这 条 专线 , 于 是 我 们 马上 和 用 户 部 门 进行 确认 , 得 知 
由 于 今天 视频 电话 会 议 系 统 主线 路 故障 ， 所 以 临时 切换 到 了 备用 线路 。 至 此 ， 问 题 终于 明晰 了 ， 
电话 会 议 结束 后 ， 流 复制 也 终于 恢复 了 正常 。 

在 这 个 例子 中 , 我 们 采用 了 常用 的 排除 法 ,首先 从 源头 检查 了 CAPTURE 进程 ,发 现 该 进程 
是 正常 的 , 所 在 服务 器 的 资源 也 比较 充足 , 但 这 个 进程 经 常 出 现 流 控 现象 ,这 说 明 该 进程 捕获 的 
消息 无 法 及 时 送出 ， 从 而 导致 流 控 。 既 然 CAPTURE 进程 经 常 流 控 ， 那 么 是 不 是 由 于 APPLY Ж 
程 较 慢 导 致 的 呢 ? 于 是 我 们 马上 检查 了 APPLY 端 ， 首 先 判断 APPLY 端的 系统 资源 是 否 出 现 了 
瓶颈 ， 经 检查 发 现 资源 较为 充足 。 接 着 我 们 又 检查 了 APPLY 服务 进程 的 情况 ， 发 现 该 进程 大 多 
数 情况 下 处 于 空闲 状态 ， 也 就 是 说 这 个 进程 本 身 并 无 问题 ， 而 且 足 够 空 闸 。 既 然 排除 了 两 端 ， 
那么 重点 怀疑 的 对 象 就 是 中 间 的 PROPAGATION 进程 了 。 而 经 过 检查 发 现 每 秒 网 络 的 传输 量 不 
足 400Kbit/s， 通 过 这 一 现象 我 们 发 现 了 一 些 问题 ， 于 是 顺 了 蔷 摸 瓜 ， 利 用 操作 系统 提供 的 检查 工 
具 ， 最 终 就 找到 了 问题 原因 。 

一 般 来 说 , 从 分 析 问 题 的 总 体 思路 来 看 ,通过 现 有 的 知识 以 及 后 续 的 分 析 排 除 不 可 能 的 因素 ， 
从 而 到 近 问题 的 本 质 是 最 为 常见 的 分 析 方 法 。 如 果 我 们 的 知识 较为 丰富 , 就 可 以 排除 掉 大 多 数 不 
可 能 的 路 径 , 其 至 直接 定位 到 故障 本 身 。 不 过 如 果 从 处 理 问题 最 为 稳妥 的 方式 来 考虑 ， 即 使 问题 
现象 十 分 明显 ， 也 不 要 放弃 必要 的 验证 和 排查 ,这 样 虽然 麻烦 一 些 , 但 是 可 以 最 大 程度 地 避免 偏 
差 的 出 现 。 


15.2 ”普通 故障 的 分 析 路 线 


这 里 所 说 的 普通 故障 ， 是 指 一 般 性 的 、 常 见 的 日 常 维护 问题 ， 比 如 某 个 操作 引起 的 错误 ,这 
种 时 候 往往 会 出 现 “ORA-XXXX” 这 样 的 错误 号 。 碰 到 这 种 情况 ， 我 们 可 能 需要 通过 手头 的 技术 
资料 或 者 Metalink 网 站 ， 去 查询 这 个 Oracle 错误 所 对 应 的 含义 。 如 果 我 们 手头 暂时 没有 技术 参 
考 手册 , 也 没 法 登录 Metalink, 并 且 面 对 的 系统 是 UNIX 系统 , 那么 就 可 以 使 用 系统 的 oerr TH, 
来 查看 这 个 ORA 错误 对 应 的 含义 以 及 可 用 的 处 理 方式 。oerr 命令 的 格式 如 下 : 

oerr ora < 错误 号 > 

比如 ， 我 们 查看 ORA-1031 错误 的 含义 ， 会 得 到 如 下 结果 : 


[oracle@db ~]$ oerr ora 1031 

01031, 00000, "insufficient privileges" 

|| *Cause: An attempt was made to change the current username or password 
ithout the appropriate privilege. This error also occurs if 
tempting to install a database without the necessary operating 
ystem privileges. 

hen Trusted Oracle is configure in DBMS MAC, this error may occur 
the user was granted the necessary privilege at a higher label 
han the current login. 


— 
— 
一 一 三 ww = 
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[1 *Action: Ask the database administrator to perform the operation or grant 


11 the required privileges. 

11 For Trusted Oracle users getting this error although granted the 
NI the appropriate privilege at a higher label, ask the database 

11 administrator to regrant the privilege at the appropriate label. 


从 第 一 行 来 看 ，ORA-1031 表示 权限 不 足 。 下 面 的 Cause 介绍 了 可 能 出 现 类 似 问题 的 原因 , 
Action 介绍 了 需要 采取 的 措施 。 

对 于 大 多 数 ORA-XXXX 问题 来 说 ， 使 用 oer 工具 可 以 让 我 们 对 问题 有 一 个 初步 的 了 解 ， 大 
多 数 问题 也 可 以 根据 Cause 和 Action 的 内 容 得 以 解决 。 

如 果 оет 工具 还 不 足以 解决 问题 ,那么 Metalink 就 是 一 种 较 好 的 选择 。 登 录 Metalink 后 ， 
直接 输入 ORA-1031 进行 查询 , 可 以 得 到 大 量 关 于 这 个 错误 的 相关 技术 资料 ,包括 Bug 的 描述 等 。 
我 们 可 以 在 Metalink 上 查找 类 似 的 案例 ， 然 后 仔细 阅读 这 些 文章 ， 寻 找 解决 问题 的 方法 。 

但 不 幸 的 是 ， 在 某 些 情况 下 ， 我 们 可 能 无 法 通过 ORA-XXXX 错误 找到 问题 ， 或 是 看 不 到 明 
确 的 ORA-XXXX 错误 。 这 时 该 如 何 进 行 分 析 呢 ? 

有 了 时候, 我 们 在 进行 某 个 操作 时 系统 会 突然 出 现 ORA-3113 之 类 的 错误 , 然后 会 话 就 断 开 了 。 
很 可 能 在 客户 端 出 现 ORA-3113 错误 前 ， 后 台 已 经 出 现 了 ORA-600. ORA-7445 之 类 的 错误 。 这 
种 情况 下 , 我 们 可 以 直接 打开 alert log 文件 , 查看 是 否 存在 错误 信息 。 如 果 找 到 了 ORA-600 或 者 
ORA-7445 的 信息 ,下 一 步 要 做 的 就 是 找到 错误 相关 的 trace 文件 ,并 保存 起 来 。 然 后 在 Metalink 
上 根据 错误 参数 查找 相关 的 资料 。 一 般 来 说 ， 对 于 ORA-600 错误 ， 我 们 只 需要 查找 其 第 一 个 参 
数 对 应 的 信息 。 比 如 ， 查 找 ORA-600 [504]， 输 入 查询 条 件 后 ,屏幕 上 会 显示 出 所 有 查找 到 的 结 
R, WA 15-1 所 示 。 由 于 Oracle 的 知识 库 十 分 庞大 ， 有 时 我 们 查 出 的 技术 资料 可 能 会 非常 多 ， 
如 果 要 缩小 查询 范围 , 可 以 点 击 左边 的 导航 条 信息 。 比 如 , 查找 Oracle 数据 库 的 资料 时 ， 可 以 点 
击 Oracle Database Products 来 进一步 缩小 显示 资料 的 范围 。 
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Patches tt Bug 10622001 Database crash ORA-600 [504] [ksfv messages] / ORA-7445 [ksfvidmp] This ~. Occur (ORA-600) ORA-600 [504] Dump in 
Y. Product Category [Artide 10 10622001.8] 


03Feb 2012 ORA-600 [504] "Trying to obtain a latch which Б already held" 
[Id ecu 0 ным This article discusses the internal error "ORA-600 [504]", what it means and possible actions. The Format: ORA-600 [504] [s] [b] [c 
Orade Database Products (152) Tags: ix ed [Artide ID 28104.1] 


rade E-Business Suite (2) 图 140ct2010 ORA- g System Flush Shared. Pool 
ЕГУГЕ ЧИИ ср guments: [504], [0x700000000070528 ~. This is > ORA-600 [504] DURING FLUSH SHARED. POOL dosed as а dupicate of Base > ORA-00600 [99999] , ORA 
T shored pool [Artide ID 428226.1] 
Configure (4) Tr ijo oct 2011 DBUA Error ORA-04031 unable to alocate 4120 bytes of shared memory, ORA-01034: ORACLE not avalable, ORA-00600: internal error code, 
кф at arguments: [504] 


Copyright (c) 2007, 2011, Orade. Al rights reserved. Legal Notices and Terms of Use | Privacy Statement | 3rd Party Licenses 


x а тА 
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图 15-1 
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上 面 的 查找 操作 是 很 简单 的 ,但 是 令 绝 大 多 数 DB A 头痛 的 是 , 虽然 查 到 了 大 量 的 技术 资料 ， 
但 还 是 不 知道 哪个 文档 才 是 有 用 的 。 在 图 15-1 H, WAT bug 10214450, bug 10622001 等 查询 
结果 ， 到 底 是 哪个 Bug 引起 了 错误 呢 ? 这 就 需要 我 们 认真 查看 刚才 找到 的 trace 文件 , 从 中 查找 
对 应 的 进程 、 出 错时 正在 执行 的 SQL， 通过 这 些 内 容 再 进行 筛选， 进一步 查找 是 否 存 在 相关 的 
资料 。 

如 果 找 到 了 类 似 的 资料 ， 那 么 就 需要 判断 其 n о n ss 
如 果 相 似 ， 下 一 步 就 要 比 对 trace 中 的 栈 信息 ， 如 果 栈 信息 也 十 分 相似 ， 那 么 这 个 文档 所 述 的 内 
容 和 系统 当前 出 现 的 问题 相同 的 可 能 性 就 很 大 了 。 接 下 来 ， ue um. 看 看 
这 类 问题 该 如 何 处 理 。 

下 面 通过 一 个 示例 来 解释 这 个 过 程 
模块 无 法 正常 工作 : 

Tue Apr 15 22:27:17 2008 

Errors in file /opt/oracle/admin/orcl/udump/ orcl 


ORA- 00600: internal error code, arguments: 
[] 


首先 ， 我们 会 根据 alert log 文件 的 内 容 找到 orcl_ora_5985.tre i 


*** 2008-08-15 22:27:17. 443 
ksedmp: internal or fatal error 
ORA-00600: internal error code, 
[] 

Current SQL statement for this session: 


于 是 我 们 到 Metalink 上 去 搜索 ， 搜 索 结 果 如 图 15-2 Bros 


。 比 如 ， 系 统 突然 出 现 了 ORA-600 错误 ， 导 致 某 个 业务 


ora 5985.trc: 


[qesmmCVal Stat4], [3], [1], 11, 11,11,11, 


这 个 文件 ， 该 文件 的 信息 如 下 : 


arguments: [qesmmCVal Stat4], [3 


Ll [b 01, 0), 0). 01, 
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Documentation hash join. enabled [Artide ID 360811.1] 
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接 下 来 ， емнех 行 排查 和 分 析 。 幸 运 的 是 ， 这 次 查询 只 找到 了 13 RER, 
不 过 查 出 的 数据 较 少 也 可 能 意味 着 这 次 查询 找 不 到 针对 性 的 结果 。 

第 一 个 条 目 是 “Connect by Query Fail With ORA-600 [Qesmmcvalstat4] [ID 360811.1]”， 我 们 
检查 了 trace 文件 中 的 Current SQL， 这 个 语句 就 在 ORA-600 错误 信息 的 后 面 ， 很 容易 找到 。 在 
Current SQL 中 ， 我 们 看 到 : 


FROM prod. OFFERING 2 PRICE PLAN O2PP, prod.PRICE PLAN PP 
WHERE 02PP.PRICE PLAN CD = РР. РАІ СЕ PLAN Ср) 

CONNECT BY PRIOR A = С 

START WITH C IS NULL) 


~ CONNECT BY 子 句 ， 看 样子 我 们 这 回 比较 幸运 ， 很 可 能 找到 了 问题 的 根源 ， 
不 过 还 需要 进一步 确认 。 打 开 这 个 文档 后 ， 我 们 看 到 : 


Applies to: 
Oracle Server - Enterprise Edition - Version: 9.2.0.7 to 10.2.0.1 - Release: 9.2 to 
10.2 
Information in this document applies to any platform 
***Checked for relevance on 26-Oct-2010*** 
Sy mpt o ms 
ORA-600 [gesmmCValStat4] on select with connect by: 
ORA-00600: internal error code, arguments: [qesmmCValStat4], [3], [1] 
Current SQL statement for this session: 
select 
start with ... ... connect by prior .. 
The stack trace shows 
qesmmCValidateStatus qesmmCStartWorkArea qerhjlnitializeManagement Components 
qerhjFetch ... 
Changes 
You may have applied the patch for the Bug 4074409, but still get the same errors 
Cause 
This is due to Bug 4926357, which is closed as duplicate of unpublished Bug 4401437. 
Unpublished Bug 4401437 is fixed in versions 10.1.0.5, 10.2.0.2, 11.1 and above 
Solution 
To implement the solution, please execute the following steps 
1. Check if there is an one-off patch for your platform and version (Patch 4401437) 


or 

2. Upgrade the database to a version where unpublished Bug 4401437 is fixed (see above) 
or 

3. For version 9.2: Set hash join enabledzfalse 

or 


4. Add a 'no filtering' hint. Please note that this workaround should not be used in 
version 9.2.0.7 due to Bug 4752555 'Wrong results from CONNECT BY query', which can 
cause an incorrect number of rows to be returned 


不 难看 出 ， 这 个 问题 涉及 的 版 本 是 9.2.0.7 ~ 10.2.0.1， 而 当前 系统 的 版 本 是 9.2.0.8， 正 好 符 
合 这 个 范围 。 距 离 问 题 又 近 了 一 步 ， 继 续 往 下 看 。 这 个 Bug 的 成 因 是 由 于 修复 bug 4074409 的 补 
丁 存在 问题 。 经 过 确认 ，bug 4074409 的 修复 补丁 的 确 包含 在 9.2.0.8 版 本 中 ， 在 这 一 点 上 也 是 吻 
合 的 。 下 面 我 们 就 需要 分 析 栈 了 ， 这 份 文档 指出 的 Bug 的 典型 栈 是 : 


15.2 
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The stack trace shows 


qesmmCValidateStatus qesmmCStartWorkArea qerhjlnitializeManagement Components 


qerhjFetch ... 


于 是 ， 我 们 分 析 trace 文件 中 的 栈 信息 : 


ksedmp() +528 
ksfdmp() +64 

kgeri nv() +400 
kgeasnmierr() +144 
[qesmmCValidateStatu 
s() +560 


$cold qesmmCStart Wo 
rkArea() +3296 


qerhjlnitializeMana 
gement Components() + 
136 


gerhjFetch() +1392 


rwsfcd() +240 
qeruaFetch() +448 
qersoFetch() +1360 
qervwFetch() +320 
qercoFetch() +400 
qerflFetchOutsi de() 
+272 
$cold gercbiFilterD 
ata() +1296 
qercbiFetch() +2448 
rwsfcd() +240 
qeruaFetch() +448 
kpofrws() +288 
opifch2() +3168 
opiall0()46128 
kpoal 8() +2272 
opiodr() *3088 
ttcpip() +1888 


cal 
cal 
cal 
cal 
cal 


cal 


cal 


cal 


Ca 
са 
са 
са 
са 
са 


са 


са 
са 
са 
са 
са 
са 
са 
са 
са 


0000000000000000 
0000000000000000 
0000000000000000 
0000000000000000 
0000000000000000 


0000000000000000 


0000000000000000 


qerhjlnitializeMana 
gement Components() + 
136 


«kernel» 
«kernel» 
«kernel» 
c000001fb0cec338 
c000001fb0cec338 
c000001fb0cec338 


c000001fb0cec338 


c000001fb0cec338 
qercbiFetch() +2448 
qercbiFetch() +2448 
qercbiFetch() +2448 
qercbiFetch() +2448 
_etext f()423058430 
0000000000000002 
9f ffffffffff9b98 
9f ffffffffff9d38 


000000000 ? 

000000003 ? 

600000000004F280 
600000000004F280 
600000000004F280 
600000000069A6C8 
40000000008ADEF0 ? 


~ - — ә 


000000002 ? 000000004 ? 
000000003 ? 000000004 ? 


000000001 ? 
9FFFFFFF7F420DD0 ? 
000000001 ? 
C000000000000795 ? 
40000000015E7460 ? 
0000081Е0 ? 
6000000000524B48 
C000002043A0E440 
C00000000000122C 
4000000001B0B1B0 
00000802D ? 
40000000008ADC10 ? 
9FFFFFFF7F420DD0 ? 
6000000000531E18 ? 
6000000000530288 ? 
C000001FE84A2EE0 ? 
C0000000000052AB ? 
400000000224FAD0 ? 
0000080ED ? 
QFFFFFFFFFFF7A70 ? 
6000000000531560 ? 
C000001FE84A2EE0 ? 
9FFFFFFF7FAIEE08 ? 
C000001FE84A2990 ? 
C000001FE84A2908 ? 
C000001FE84A28B0 ? 
C000001FE84A2858 ? 


000000000 ? 000000000 ? 


40000000012988D8 ? 
40000000012988D0 ? 
C000001FB0CEC338 ? 
C000001FB0CEC338 ? 
9FFFFFFF7F421228 ? 
C00000201942CA98 ? 
9FFFFFFF7F4F34A0 ? 
9FFFFFFFFFFF8360 ? 
000000002 ? 

9FFFFFFFFFFF9ADO ? 
9FFFFFFFFFFF9E80 ? 
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opitsk() +1920 cal _etext_f()+23058430 6000000000052C40 ? 

opiino() +2656 cal _ text start f()495 000000000 ? 000000000 ? 

opi odr() +3088 cal — text start f()495 60000000005Е3С08 ? 

opi drv() +1088 cal 9fffffffffffd7e8 9FFFFFFFFFFFD930 ? 

sou20() +48 cal 9fffffffffffd7e8 9FFFFFFFFFFFE980 ? 

mai n() +352 cal 9fffffffffffd7e8 9FFFFFFFFFFFEF00 ? 

main opd entry()480 cal 9fffffffffffd7e8 000000000 ? 

我 们 注意 到 ， 方 括号 括 起 部 分 的 栈 信息 和 文档 中 的 信息 完全 一 致 ， 这 说 明 到 目前 为 止 ，Bug 


的 吻合 度 是 100% ， 极 有 可 能 是 这 个 问题 引起 的 〈 为 了 保持 本 节 的 简洁 ， 我 重新 编排 了 CALL 
STACK 的 信息 , 保留 了 CALLSTACK 中 所 有 的 function call, 但 是 删除 了 一 些 多 余 的 信息 , 分析 
CALL STACK 中 的 所 有 function call 是 否 和 自己 的 情况 吻合 是 十 分 关键 的 )。 那 么 该 如 何 进一步 
验证 呢 ? 我 们 来 看 一 下 文档 中 的 解决 方案 ， 也 就 是 SOLUTION 这 一 节 。 这 里 提出 了 4 个 解决 方 
Жж, 一 是 更 新 这 个 Bug HAT; 二 是 升级 到 已 经 修复 了 这 个 Bug 的 版 本 ; 三 是 设置 
HASH_JOIN_ENABLED=FALSE， 关 闭 HASH JOIN; 四 是 使 用 no filtering 提示 。 

接 下 来 , 我 们 将 SQL 完整 地 取出 ,首先 在 SQL*Plus 下 执行 这 条 SQL, 确实 每 次 执行 都 会 报 
错 ， 然 后 我 们 在 会 话 级 设置 HASH JOIN ENABLED-FALSE, 错误 就 消失 了 。 使 用 no filtering 
测试 ， 也 能 够 成 功 执行 。 至此， 我 们 基本 上 可 以 定位 ORA-600 错误 和 这 个 Bug AXT, WAF 
一 步 就 是 向 领导 申请 停机 更 新 补丁 的 时 间 ， 通 过 补丁 彻底 解决 这 个 问题 。 

本 节 向 大 家 介绍 了 普通 Oracle 问题 的 分 析 与 解决 思路 。 其实, 解决 问题 的 方法 有 很 多 种 ,每 
个 DBA 都 有 自己 的 思维 方式 ,这 里 介绍 的 只 是 老 白 分 析 问 题 最 常用 的 思路 ,并 不 要 求 所 有 的 DBA 
都 放弃 自己 的 思考 方式 ， 采 用 和 老 白 一 样 的 方法 。 另 外 ,每 个 DBA 都 有 自己 的 知识 库 体 系 ， 在 
通过 Metalink 查找 问题 前 , 也 可 以 先 查 找 自己 的 知识 库 , 不 过 前 提 是 确保 该 知识 库 的 正确 性 ， 否 
则 可 能 会 影响 处 理 结 果 。 在 某 些 情况 下 ，Metalink 可 能 无 法 访问 ， 因 此 保留 一 个 离线 的 Metalink 
知识 库 是 十 分 必要 的 。 早 期 的 Metalink 不 是 通过 HTTPS 协议 连接 的 ， 可 以 通过 工具 去 抓 取 离线 
数据 ， 而 现在 已 经 无 法 抓 取 离 线 版 本 了 ， 因 此 只 能 通过 日 常 的 积累 ， 逐 渐 丰 富 自己 的 知识 库 。 


15.3 ”性 能 问题 的 分 析 路 线 


在 上 一 节 我 们 讨论 了 普通 的 Oracle 问题 的 分 析 思 路 ， 这 一 节 重 点 来 讨论 性 能 问题 的 分 析 方 
法 。 人 性 能 问题 的 处 理 方式 和 普通 故障 有 所 不 同 ， 发 现 一 般 性 能 问题 的 途径 包括 以 下 几 个 方面 。 

а 客户 投诉 。 客 户 系 统 出 现 性 能 问题 ， 向 IT 部 门 投诉 。 一 般 来 说 ， 对 于 没有 完善 一 线 管 理 
的 系统 ， 这 是 最 可 能 的 发 现 问题 的 途径 ， 但 因为 客户 对 于 系统 性 能 下 降 的 感受 较为 滞后 ， 
可 能 很 难 判断 出 某 个 操作 端 到 端的 响应 时 间 是 200 毫秒 还 是 500 毫秒 , 因此 , 只 要 不 出 现 
性 能 大 幅度 下 降 ， 客 户 的 主观 感受 较为 迟钝 。 

а 监控 报警 。 对 于 已 经 建立 了 维护 基线 ， 并 进行 全 面 一 线 监 控 的 系统 来 说 ， 可 以 通过 监控 
报警 来 更 早 地 发 现 系统 存在 的 性 能 问题 。 监 控 系 统 对 系统 性 能 问题 的 敏感 度 远 远 高 于 客 
户 ， 只 要 设置 了 合理 的 基线 数据 ， 那 么 监控 系统 就 可 以 帮助 我 们 及 时 发 现 系统 出 现 的 问 
题 。 这 里 需要 指出 的 是 ， 基 线 管理 并 不 像 想象 的 那么 简单 ， 不 是 随便 设置 一 些 参数 就 可 
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以 实现 自动 监控 的 。 我 们 必须 设置 合理 的 基线 数据 ， 如 果 基 线 设 置 过 于 宽大 ， 那 么 就 有 
可 能 把 一 些 隐患 掩盖 掉 ， 一 些 本 应 该 报警 的 场景 被 直接 过 滤 了 ， 达 不 到 防 患 于 未 然 的 目 
的 ; 如 果 基 线 设 置 偏 严 格 ， 那 么 可 能 出 现 大 量 的 误 报 ， 从 而 导致 运 维 团队 风声 箱 噢 ， 最 
终 大 家 对 于 监控 报警 直接 忽略 ， 从 而 失去 了 报警 的 意义 。 

а 事后 分 析 。 这 也 是 我 们 经 常 磁 到 的 、 十 分 无 奈 的 处 理 模式 。 由 于 问题 已 经 发 和 后， 而 且 故 
障 出 现时 为 了 尽快 解决 问题 ， 往 往 缺 乏 必要 的 数据 采集 ， 因 此 我 们 能 够 掌握 的 分 析 数 据 
极为 有 限 ， 从 而 大 幅 降 低 了 问题 被 准确 定位 的 可 能 性 。 

对 于 不 同 的 场景 ,我 们 所 采取 的 分 析 路 线 图 也 会 有 所 不 同 。 在 发 生 现场 故障 时 ， 对 于 核心 的 
企业 级 应 用 系统 而 言 ， 分 析 和 处 理 故 障 的 时 间 极 为 有 限 ， 用户 单位 会 有 严格 的 解决 时 限 。 对 于 很 
多 企业 级 用 户 来 说 ， 如 果 问 题 能 够 在 30 分 钟 内 解决 ， 那 么 此 类 故障 不 会 影响 维护 团队 的 绩效 ; 
否则 就 可 能 会 影响 绩效 。 因 此 ，30 分 钟 是 每 个 现场 支持 工程 师 都 无 法 回避 的 死 限 。 如 何在 30 分 
钟 内 解决 问题 往往 是 现场 工程 师 首先 面 对 的 问题 。 所 以 说 , 现场 故障 处 理 的 目标 不 是 彻底 搞 清楚 
问题 的 根源 在 哪里 ， 而 是 首先 恢复 系统 的 正常 运作 。 

一 般 来 说 ， 如 果 系 统 出 现 了 较为 明显 的 性 能 问题 ， 会 体现 在 以 下 几 个 方面 : 

口 关键 业务 受到 了 影响 ; 
а 系统 整体 性 能 不 佳 ; 

口 某 些 关键 流程 比较 慢 ; 

Q 存在 突 发 的 负载 增加 ; 
а 某 项 系统 资源 存在 瓶颈 。 

如 果 某 些 关 键 业 务 平时 的 性 能 良好 , 却 在 某 个 时 间 突 然 出 现 问题 , 那么 就 说 明 肯 定 有 一 些 特 
殊 的 情况 存在 。 很 多 ОВА 在 磁 到 问题 时 总 是 急 急 忙 忙 地 采取 技术 手段 去 分 析 和 解决 问题 。 尽 管 
情况 很 紧急 , 但 不 进行 任何 调查 研究 就 急于 动手 , 是 非常 不 好 的 习惯 。 老 白 这 些 年 已 经 养 成 了 一 
个 很 好 的 习惯 ， 在 碰 到 这 类 问题 的 时 候 ， 首 先 会 让 客户 协助 了 解 以 下 情况 : 

a 出 问题 前 ,或 者 前 一 天 晚上 ， 系 统 是 否 进行 了 升级 ， 应 用 软件 有 无 新 模块 或 者 补丁 发 布 ; 
O 出 问题 前 ,或 者 前 一 天 晚上 ， 进 行 了 哪些 维护 工作 ; 

а 今天 在 系统 上 进行 过 哪些 特殊 的 操作 ? 比如 ， 一 些 特殊 的 批 处 理 业务 ， 或 者 系统 备份 这 
类 可 能 对 系统 有 较 大 影响 的 操作 ; 

a 今天 业务 部 门 是 否 进 行 了 可 能 导致 某 个 业务 模块 工作 负载 大 幅度 增加 的 活动 。 

这 些 问题 完全 可 以 交 给 其 他 人 去 做 , 而 不 需要 自己 一 一 确认 。 而 且 这 项 工作 可 以 和 分 析 工 作 
同步 进行 ， 这 样 就 能 大 幅 加 快 问题 分 析 的 速度 。 

有 一 次 ， 老 白 去 给 客户 的 系统 做 健康 检查 ， 刚 到 现场 ， 就 发 现 所 有 的 维护 人 员 都 围 在 一 个 工 
位 前 , 神色 紧张 。 询 问 了 一 下 才 知 道 , 今天 一 上 班 ， 系统 的 CPU 使 用 率 就 达到 了 100% ， 而 平时 
这 个 系统 的 CPU 使 用 率 不 足 50%， 所 有 的 业务 部 门 都 在 报 故障 ， 系 统 很 慢 ， 已 经 严重 影响 了 营 
业 厅 的 业务 。 

我 没有 立即 去 分 析 问 题 , 而 是 问 他 们 前 一 天 晚上 进行 了 哪些 维护 操作 ,他 们 想 了 想 说 , 没 做 
过 什么 。 后 来 ， 有 一 个 DBA 想起 来 了 ， 昨 天 快 下 班 的 时 候 应 用 开发 厂商 让 他 给 一 张 表 加 了 一 个 
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索引 。 于 是 我 们 立即 生成 了 一 份 STATSPACK 报告 , 我 从 报告 中 发 现 , 确实 存在 几 条 开销 很 大 的 
SQL， 从 执行 计划 上 看 ， 这 些 SQL 都 使 用 了 昨天 新 建 的 索引 ， 而 从 业务 的 角度 来 看 ， 使 用 这 些 
索引 是 不 合适 的 。 于 是 我 们 马上 对 这 张 表 和 相关 索引 进行 了 分 析 ,， 分 析 完 成 后 ， 系 统 负载 逐渐 下 
降 ，10 多 分 钟 后 ，CPU 负载 也 降低 到 了 50% 以 下 。 
老 白 通常 把 这 种 处 理 故 障 的 过 程 称 为 “快捷 方式 ”， 就 是 通过 经 验 和 所 掌握 的 信息 ， 快 速 排 
除 其 他 的 可 能 性 ， 从 而 定位 问题 的 一 种 方法 。 快 捷 方式 需要 处 理 问 题 的 人 不 仅 技 术 能 力 较 强 ,处 
理 问题 的 经 验 很 丰富 ， 而 且 需 要 对 系统 比较 了 解 ， 并 且 能 够 准确 掌握 相关 的 资讯 。 

如 果 使 用 快捷 方式 失败 , 那么 就 会 浪费 宝贵 的 分 析 时 间 。 如 果 我 们 连续 几 次 问题 定位 都 失败 
了 ,那么 就 必须 放弃 使 用 快捷 方式 , 而 是 采用 常规 的 分 析 方 法 来 进行 分 析 。 常 规 分 析 往 往 是 一 种 


采用 自 底 向 上 的 方法 是 通过 现象 往 本 源 方面 推 岂 , 而 采用 上 自 顶 向 下 的 方法 是 从 本 源 向 现象 推 
断 ， 根 据 我 们 现 有 的 知识 ,按照 一 定 的 预案 进行 分 析 、 排 除 ， 从 而 逼近 问题 点 。 整 个 诊断 路 线 图 
就 是 不 断 排 除 、 缩 小 范围 的 过 程 。 虽然 有 时 我 们 看 到 的 现象 是 一 样 的 , 但 是 造成 该 现象 的 本 源 可 
能 大 相 径 庭 ， 因 此 我 们 在 分 析 时 ， 如 何 按 照 正确 的 道路 前 行 是 十 分 关键 的 。 首 先 来 看 图 15-3 所 
示 的 图 例 。 


性 能 分 析 的 起 点 等 待 事件 /系统 开销 

OS 和 数据 库 日 志 

系统 及 SQL 情况 top sql/top session 

wer ae 
profiler PL/SQL 情况 OWI 及 性 能 分 析 awr,ash,statspack 
{ Y 
autotrace, 10046 JEAN Hangnaalyze 分 
awr,dbms xplan SQL 执行 计划 du 
系统 调用 tusc,truss,pstack 
图 15-3 


当 我 们 碰 到 性 能 故障 时 , 首先 需要 了 解 系统 等 待 事件 和 系统 资源 开销 的 情况 。 查 看 操作 系统 
是 否 出 现 了 CPU 或 者 内 存 不 足以 及 换 页 的 现象 。 如 果 是 内 存 不 足 导致 了 换 页 ， 那 么 下 一 步 就 需 
要 分 析 产 生 换 页 的 原因 ， 是 物理 内 存 确实 不 足 , 还 是 系统 的 某 些 问题 导致 了 会 话 数量 增加 ， 从 而 
耗 尽 了 内 存 ， 又 或 者 是 某 个 Bug 导致 Oracle 进程 出 现 了 内 存 泄漏 ， 使 一 些 进程 消耗 了 过 多 的 内 
存 。 这 种 情况 下 , 杀 掉 部 分 消耗 内 存 较 大 的 进程 可 能 就 能 够 暂时 缓解 问题 ,但 是 找到 问题 的 根本 
原因 也 是 十 分 重要 的 。 

除了 内 存 、CPU 外 ， 还 必须 检查 网 络 ， 这 也 是 我 们 经 党 忽视 的 问题 。 通 过 netstat 等 工具 检 
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查 网 络 是 否 存在 问题 ， 通 过 ping 大 数据 包 或 者 ftp/sftp 等 方式 检查 网 络 传输 能 力 ， 这 些 都 是 排查 
网 络 问题 的 常用 方法 。 

如 果 我 们 发 现 CPU 使 用 率 是 100%， 而 平时 这 个 系统 的 CPU 使 用 率 总 是 小 于 60%, ABA RT 
需要 分 析 到 底 是 什么 原因 导致 了 CPU 使 用 率 上 升 。top/topas 或 者 glance 这 类 工具 在 这 种 分 析 中 
十 分 有 用 。 我 们 可 以 通过 top 命令 来 查看 是 否 存在 某 些 大 量 消耗 CPU 资源 的 进程 , 如 果 发 现 了 这 
些 进程 ， 就 需要 进一步 分 析 这 些 进程 当前 的 情况 ， 然 后 通过 V$SESSION 视图 来 检查 这 些 Oracle 
会 话 的 作用 ， 当 前 正在 进行 哪些 操作 ， 最 后 分 析 这 些 操 作 ， 找 到 问题 的 根源 。 

如 果 我 们 没有 在 top 中 发 现 异常 , 虽然 CPU 使 用 率 很 高 , 但 是 找 不 到 明显 的 、 开 销 很 大 的 进 
程 ， 那 么 就 无 法 根据 这 条 线索 往 下 分 析 。 因 此 ， 我 们 下 一 步 就 应 该 检查 系统 的 各 种 日 志 ， 包 括 
Oracle 的 ALERT LOG 文件 、 操 作 系 统 的 日 志 、 集 群 日 志 等 。 如 果 有 条 件 ， 还 应 该 通知 硬件 、 存 
储 和 网 络 维护 部 门 检查 服务 器 、 网 络 和 存储 设备 是 否 正常 ， 是 否 存在 明显 的 报错 。 

对 于 DBA ii, ALERT LOG 文件 是 检查 的 重点 。 在 该 文件 中 ， 我 们 应 重点 检查 是 否 出 现 
报错 ， 比 如 ORA-600, ORA-7445, ORA-4031, ORA-3113, ORA-3116, IPC SEND/RECEIVE 
TIMEOUT 等 ， 如 果 发 现 了 报错 信息 ， 就 应 该 进一步 判断 这 些 问题 是 否 和 系统 变 慢 有 关 ( 很 可 能 
绝 大 多 数 ALERT LOG 的 报错 都 和 系统 变 慢 无 关 ， 因 此 我 们 也 不 能 草木 器 兵 ， 必 须 认 真 分 析 ,， 才 
能 得 出 结论 )。 

如 果 没 有 在 ALERT LOG 文件 中 发 现 什么 有 价值 的 信息 ， 那 么 接 下 来 就 需要 通过 OWI TA. 
来 检查 系统 目前 的 状态 ， 查 看 VSSESSION WAIT 中 的 主要 等 待 事件 是 否 存在 异常 ， 和 我 们 平时 
看 到 的 等 竺 事件 有 无 不 同 。 经 常 管理 这 个 系统 的 DBA 可 能 很 了 解 本 系统 平时 的 情况 ， 但 一 个 刚 
接触 这 套 系统 的 人 ， 并 不 清楚 这 套 系统 平时 是 什么 样 的 ， 而 V$SESSION_WAIT 中 的 等 待 事件 又 
不 存在 很 严格 的 正常 情况 和 非 正常 情况 , 那么 可 能 就 需要 花费 更 多 的 精力 对 大 量 的 等 待 事件 进行 
分 析 和 排查 , 这样 就 增加 了 分 析 问 题 的 时 间 。 因 此 ,在 维护 过 程 中 ,记录 系统 的 一 些 正常 指标 是 
十 分 关键 的 。 我 们 可 以 把 下 列 SQL 运行 后 的 结果 保存 起 来 ， 作 为 基线 。 

select count(*),event from v$session wait group by event order by count(*) 

一 旦 系统 出 现 问题 ， 我 们 在 进行 分 析 时 ,可 以 将 查询 结果 和 这 个 基线 数据 进行 比较 , 这 样 就 
很 容易 发 现 其 中 存在 的 问题 了 。 

另外 还 需要 注意 当前 正在 执行 的 SQL, 很 多 情况 下 , 系统 出 现 的 问题 并 不 是 由 某 一 个 消耗 了 
过 多 资源 的 会 话 引起 的 ， 而 是 由 于 大 量 的 并 发 小 SQL 导致 的 。 有 些 平时 开销 很 小 的 SQL 往往 会 
被 我 们 忽视 ， 但 当 这 些 SQL 的 平均 执行 开销 增加 30%， 或 者 并 发 量 增加 30% 时 ， 就 有 可 能 给 系 
统 带 来 致命 的 打击 。 

在 10g 版 本 中 ， 我 们 可 以 通过 SQL. ID 来 分 析 是 否 存 在 一 些 导致 系统 问题 的 SQL 语句 。 在 
9; 或 者 更 早 的 版 本 中 ， 我 们 可 以 使 用 SQL 的 HASH_VALUE 来 代 奉 SQL 1р. 

select count(*), SQL ID from v$session wait group by SQL ID order by count(*) 

但 是 如 果 我 们 遇 到 的 是 一 套 代 码 很 不 规范 的 系统 ， 没 有 使 用 绑 定 变量 ， 那 么 就 无 法 通过 
SQL ID 来 查找 存在 问题 的 SQL 了 。 这 种 情况 下 ， 一 些 抓 取 TOP SQL 的 工具 也 会 失去 作用 ， 
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IE, ASH 报告 和 AWR 报告 将 是 分 析 问 题 的 有 力 工具 。 


如 果 我 们 在 故障 现场 ， 而 正好 系统 安装 并 启用 了 DB CONSOLE 或 者 GRID CONTROL, 3f 
Z EM 优秀 的 性 能 分 析 和 SQL 优化 工具 会 带 


具 会 带 来 很 大 的 帮助 。 这 里 ， 登 录 EM 并 调 出 顶级 活动 管 
理 页 面 ， 如 图 15-4 所 示 。 
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通过 顶级 活动 的 曲线 图 , 我 们 可 以 看 到 系统 在 某 个 时 段 出 现 了 高 峰 , 拖 动 时 间 窗 口 到 某 个 位 
置 ， 在 本 页 面 的 下 方 就 会 显示 TOP SQL 和 TOP SESSION 的 情况 。 如 果 发 现 某 条 SQL 可 能 存在 
问题 ， 只 需 点 击 记 


点 击 这 条 SQL， 就 可 以 对 该 SQL 进行 分 析 及 在 线 优 化 ， 如 图 15-5 和 图 15-6 所 示 。 
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Мойше SQL*Plus Elapsed Tire (sec) 1556.43 
Action CPU Tirre (sec) 380.96 
Parsing Schema SH Concunenc Wait Time (ser) 1175.47 
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Total Parses 4 Total Per Execution Per Row Exccutionc that Fetched all Rows (25) 0.00 
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Child Cursors 1 >, Average Runtime Mem (KB) 3.63 
Child Cursors With Loaded Plans 1 SEU Tune (cee) s, = 7 m ЧА Serializatle Aborts 0 
Invalications Ü Bufor Geo SEN 2150237 728755925 Remote No 
Largest Cursor Size (KB) 21.99 Disk Reads 0 0.00 NA Obsolete No | 
All Cursor Size (KB) 21.99 Direct Writes 0 0.00 NA Child Latch Number 1 
First Load Time Apr 19, 2005 4:20:34 АМ Rows 0 0.00 NA 
Last Load Time Apr 19, 2005 4:20:34 AM Fechos 4 1.00 NA 


图 15-6 


我 们 还 可 以 直接 在 EM 中 分 析 执 行 计划 ， 如 图 15-7 所 示 。 
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如 果 我 们 自身 的 分 析 能 力 不 足 ， 或 者 不 想 伤害 更 多 的 脑 细胞 ， 那 么 就 可 以 直接 调用 SQL E 
化 助手 进行 分 析 ， 运气 好 的 话 ， 能 够 马上 得 到 优化 方案 , 并 直接 在 EM 中 提交 优化 方案 ， 进 行 现 

不 过 有 可 能 我 们 并 没有 那么 幸运 ， 也 许 系统 根本 就 没有 配置 DB CONSOLE, 或 者 DB 
CONSOLE 无 法 使 用 ， 那 么 我 们 就 只 能 依靠 自己 的 双手 ， 多 费 点 脑子 了 。 这 时 ASH 报告 和 AWR 
报告 就 十 分 有 用 了 。 

很 多 朋友 在 分 析 问 题 时 很 喜欢 套用 以 往 的 经 验 , 这 样 确 实 可 以 缩小 分 析 的 范围 , 达到 事 半 功 
倍 的 效果 。 但 如 果 我 们 一 味 地 墨守成规 , 那么 经 验 不 但 不 会 帮助 我 们 , 还 会 带 来 很 大 的 负面 作用 。 
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因为 尽管 问题 的 表象 可 能 很 相近 ， 但 是 其 根源 却 大 不 相同 。 比 如 ， 下 面 这 两 个 案例 的 表象 都 是 
CPU 使 用 率 100%, 不 过 经 过 分 析 发 现 , 是 由 截然 不 同 的 原因 导致 的 。 首 先 我 们 来 看 第 一 个 案例 : 


HP-UX hpux-01 B.11.11 U 9000/800 07/25/05 


12:47:04 %usr Wsys %wi 0 %i dle 
12:47:09 31 69 0 0 
12:47:14 20 80 0 0 
12:41:19 11 89 0 0 
12:47:24 22 18 0 0 
12:47:29 23 11 0 0 
12:47:34 14 86 0 0 
12:47:39 1 93 0 0 
12:47:44 10 90 0 0 


从 数据 上 看 ，CPU 的 IDLE 为 0，SYS CPU 的 比例 很 高 。 这 种 情况 下 ，USER 的 CPU 使 用 率 
不 高 ， 因 此 不 太 可 能 是 由 于 大 量 SQL 扫描 数据 导致 的 。 以 老 白 的 经 验 来 看 ， 有 两 种 情况 可 能 | 
最 大 ， 在 系统 换 页 或 者 LATCH SPIN 很 严重 时 ， 都 会 出 现 大 量 的 SYS CPU 消耗 。 这 里 ，WIO 的 
数据 为 0, 而 如 果 换 页 大 量 出 现时 , УЛО 不 可 能 为 0, 因此 我 们 更 倾向 于 LATCH SPIN。 通 过 vmstat 
检查 很 快 就 能 排除 系统 换 页 的 可 能 性 。 于 是 马上 采集 一 个 STATSPACK 报告 , 果然 LATCH FREE 


等 待 出 现在 top 5 event H! , 主要 体现 在 LIBRARY CACHE 和 SHARED POOL 方面 。 
Top 5 Ti med Events 


IEEE % Total 
Event Waits Time (s) Ela Ti me 
db file sequential read 1,335,960 9,089 45.46 
library cache ріп 2,411 1,008 35.05 
CPU time 1,606 8.03 
library cache load lock 684 969 4.85 
latch free 88,088 102 3.51 
可 以 看 出 ，LIBRARY CACHE PIN 排 在 第 二 位 ， 占 等 待 事件 的 35.05%， 从 后 面 的 明细 情况 
来 看 : 
Avg 

Total Wait Wait Waits 
Event Waits Ti meouts Ti me (5) (ms) [txn 
db file sequential read 1,335,960 0 9,089 1 114.8 
library cache pin 2,411 2,316 7,008 2829 0.2 


LIBRARY CACHE PIN 的 平均 等 待 时 间 为 2829 毫秒 ,超过 正常 水 平 数 百倍 (在 一 般 情 况 下 ， 


ЕЗ, 


这 个 等 待 为 几 毫 秒 )， 这 是 很 典型 的 共享 池 冲 突现 象 。 同 时 在 ALERT LOG 文件 中 也 出 现 了 大 
的 ORA-4031 报错 信息 : 


H 


H 


ОКА- 04031: 无 法 分 配 4200 FPA ("shared pool", "selecta.customer id,a.deale...', 


"library cache", "kkslpkp - literal info.") 


的 应 用 ， 然 后 刷新 共享 地， 问题 就 解决 了 。 


通过 4031 分 析 ， 我 们 发 现 共 享 池 的 空闲 比例 还 很 高 ， 于 是 决定 马上 暂停 部 分 非 7 x 24 小 时 
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另外 一 个 案例 中 ， 系 统 的 CPU «BTE, Art SYS 的 CPU 比例 并 不 高 ， 只 有 5% 左 右 ， 相 关 
的 AWR 报告 如 下 : 


Event Waits Time(s) Avg Wait(ms) % Total Call Ti me Wait Class 
CPU ti me 195,685 31.3 

db file sequential read 6,424,327 55,647 9 8.9 User 1/0 
log file sync 1,546,901 9,521 6 1:5 Commi t 
db file parallel write 5,226,356 4,519 1 m System 1/0 
gc buffer busy 620,869 3,857 6 6 Cluster 


从 报告 上 看 ， 并 没有 什么 异常 。 那 到 底 是 什么 原因 呢 ? 马上 用 topas 命令 检查 是 否 存在 高 开 
销 的 进程 ， 并 没有 发 现 特殊 的 进程 。 于 是 ， 我 通过 SQL ID 在 V$SESSION 中 对 激活 的 会 话 进行 
了 分 组 ， 发 现 居 然 有 200 多 个 活跃 会 话 在 执行 相同 的 一 条 SQL。 接 下 来 ， 通 过 awrsqrpt 比 对 了 这 
条 SQL 前 几 天 的 情况 ,发 现 执行 计划 没 变 ，CPU 开销 也 没 变 , 不 过 平均 每 次 执行 时 间 比 以 前 长 了 
七 八 倍 。 再 回头 查看 AWR 报告 , 发现 DB FILE SEQUENTIAL READ 的 平均 等 待 时 间 平 时 是 5~6 
毫秒 ， 而 现在 是 9 毫秒 ， 这 有 些 不 正常 。 经 过 分 析 和 多 方 了 解 ， 我 发 现 有 一 张 表 使 用 了 一 个 新 的 
分 区 ， 而 这 个 分 区 建 在 了 一 个 新 加 的 RAID 组 上 。 这 个 RAID 组 本 来 是 用 来 备份 文件 的 ， 所 以 做 
T RAID 5， 而 且 磁 盘 的 数量 也 较 少 ， 只 有 3 块 ， 由 于 其 他 磁盘 组 空间 较为 紧张 ， 才 把 新 的 数据 
文件 建 在 了 这 个 VG 上 。 通 过 对 新 建 的 文件 进行 分 析 ， 我 发 现 访问 这 个 文件 的 VO 性 能 确实 比 其 
他 文件 要 低 很 多 。 于 是 我 们 决定 晚上 把 这 个 数据 文件 迁 回 性 能 较 好 的 VG。 处 理 后 ， 第 二 天 系统 
就 恢复 正常 了 。 

通过 上 面 这 两 个 表象 极为 相似 但 处 理 过 程 截然 不 同 的 案例 , 我 们 应 该 明确 一 个 道理 , 那 就 是 
不 要 轻易 下 结论 ,按部就班 地 按照 CHECKLIST 一 点 点 分 析 ， 可 能 是 最 快 的 途径 。 想 要 跳 过 分 析 
环节 ， 直 接 得 出 结论 ， 在 大 多 数 情况 下 ， 可 能 会 欲 速 则 不 达 。 
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SQL 优化 是 优化 工作 中 最 为 耗 时 的 部 分 , 很 多 DBA 都 觉得 SQL 优化 是 十 分 高 深 的 工作 , 不 
敢 涉足 。 实 际 上 ， 只 要 掌握 了 基本 思路 ，SQL 优化 并 不 像 想象 的 那么 难 。 老 白 一 直 认 为 SQL 优 
化 是 一 件 体力 活 。 
SQL 优化 工作 实际 上 分 为 两 部 分 ， 首先 要 分 辨 出 哪些 SQL 需要 优化 ， 然 后 针对 这 些 SQL Ht 
行 优化 分 析 。 对 于 应 用 优化 项 目 而 言 ， 一 般 包含 以 下 几 方 面 的 工作 : 
口 查找 TOP SQL; 
о 分 析 SQL 对 系统 的 影响 ; 
口 分 析 SQL 的 优化 方法 ; 
口 制订 优化 计划 ; 
a 实施 优化 操作 ; 
а 评估 优化 效果 。 
查找 TOP SQL 的 方法 有 很 多 ， 现 在 大 家 最 常用 的 是 通过 分 析 AWR 报告 或 者 V$SQLAREA 
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来 查找 。 我 们 一 般 会 通过 某 个 时 间 窗 口 来 查找 这 上 段 时 间 内 的 TOP SQL， 这 种 查找 方式 没有 问题 ， 
不 过 要 注意 的 是 ， 不同 的 时 间 段 中 ， 如 果 系 统 执 行 的 SQL 差别 较 大 ， 那 么 就 需要 检查 所 有 的 关 
键 时 间 段 ， 查 找 可 能 存在 的 TOP SQL。 老 白 经 常 使 用 的 查找 TOP SQL 方法 包括 : 
口 AWR/STATSPACK/ADDM/ASH 报告 ; 

口 EMADDM 分 析 ; 

口 SQLA (ЖН Metalink 的 工具 ); 

O V$SQL/V$SQLAREA; 

О Oracle 9j SQLANALYZER; 

Q Oracle 9i EM TOP SQL. 

找到 TOP SQL 后 ， 我 们 不 能 埋头 就 开始 进行 SQL DUE, MEE CETL, DRAE 
优化 价值 不 大 的 SQL。 那 么 哪些 SQL 才 是 优化 价值 不 大 的 SQL YE? 

首先 ， 一 次 性 执行 的 SQL， 特 别 是 用 SOL*Plus 或 者 PL/SQL DEVELOPER 执行 的 SQL， 这 
HE SQL 往往 是 由 某 些 维护 人 员 或 者 业务 人 员 手 动 执行 的 ， 其 执行 频率 很 低 ， 而 且 经 常会 改变 ， 
优化 的 价值 不 大 。 

其 次 是 一 些 对 OLTP 系统 性 能 影响 较 小 的 批 处 理 业务 ， 这 些 SQL 虽然 周期 性 运行 ， 但 执行 
频率 很 低 ， 只 要 这 些 SQL 没有 严重 影响 到 OLTP 业务 的 性 能 ， 就 可 以 将 其 优先 级 设置 为 较 低 ， 
不 在 优化 初期 重点 分 析 。 

最 后 是 一 些 可 以 安排 在 夜间 业务 低谷 时 运行 的 批 处 理 作业 ， 这 些 SQL 往往 是 一 些 十 分 复 困 
的 统计 操作 , 优化 难度 较 大 ， 只 要 避免 其 在 白天 业务 繁忙 时 段 运行 基本 上 就 能 够 解决 问题 了 , 在 
优化 初期 先 不 要 去 哨 这 种 硬骨头 。 

在 筛选 过 程 中 , 还 需要 为 这 些 SQL 的 优化 工作 安排 优先 级 。 如 果 我 们 不 是 做 一 个 优化 项 目 ， 
而 是 应 对 一 个 突 发 事件 ， 那 么 就 应 该 尽 可 能 先 选 择 一 些 较为 简单 旦 分 析 难 度 不 大 的 SQL 进行 优 
化 ， 最 后 再 去 处 理 那 些 十 分 复杂 的 SQL。 但 如 果 我 们 是 在 一 个 优化 项 目 中 进行 SQL 优化 ， 那 么 
对 系统 性 能 影响 越 大 的 SQL， 其 优先 级 就 越 高 。 

在 分 析 和 优化 SQL 时 ， 要 注意 成 本 的 控制 ， 尽 可 能 选择 性 价 比 最 高 的 优化 方案 ， 而 不 是 性 
能 最 佳 的 优化 方案 。 如 果 有 两 种 优化 方案 , 第 一 种 是 通过 添加 一 个 索引 来 解决 问题 ,而 第 二 种 需 
要 修改 Java 代码 。 这 种 情况 下 ， 第 一 种 方案 能 够 减少 80% 的 资源 开销 ， 而 第 二 种 方案 可 以 减少 
95% 的 资源 开销 ， 那 么 我 们 该 选择 哪 种 优化 方案 呢 ?” 显 然 ， 第 一 种 优化 方案 应 该 是 我 们 的 首选 ， 
当然 在 条 件 允 许 的 情况 下 ， 比 如 软件 要 进行 升级 ， 那 么 第 二 种 方案 也 有 可 能 实现 。 

除了 成 本 外 ,还 要 考虑 风险 , 尽 可 能 规避 风险 也 是 优化 方案 选择 中 必须 考虑 的 因素 。 我 们 应 
该 尽 可 能 选择 风险 较 小 的 方案 ， 避 开 风 险 系 数 较 高 的 方案 。 

SQL 优化 的 最 佳 途径 并 不 仅仅 是 改写 SQL， 实 际 上 ， 优 化 的 方法 有 很 多 种 ， 老 白 归 纳 了 一 
些 最 为 常见 的 SQL 优化 方法 : 

о 调整 索引 ; 
О 调整 执行 计划 ; 
о 优化 相关 表 的 存储 结构 ; 
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口 数据 归档 ; 
О 表 和 索引 分 析 策 略 调整 ; 
a 调整 SQL 执行 时 间 窗 口 ; 
口 限制 数据 查询 范围 ; 
a 修改 SQL. 

调整 索引 是 优化 成 本 最 小 的 解决 方案 ， 在 老 白 参与 过 的 优化 项 目 中 ， 通 过 索引 优化 的 SQL 
大 约 占 50% ~ 60%， 超 过 一 半 的 SQL 都 是 可 以 通过 索引 进行 优化 的 。 

除了 索引 外 ， 还 有 些 SQL 的 执行 计划 存在 问题 ， 通 过 调整 执行 计划 来 优化 SQL， 减 小 其 开 
销 ， 也 是 十 分 常见 的 方法 。 

优化 相关 表 的 存储 结构 包含 十 分 广泛 的 含义 , 最 简单 的 是 调整 表 的 存储 参数 , 还 有 就 是 将 普 
通 表 改 为 分 区 表 或 者 HASH CLUSTER, IOT 等 结构 ， 当 然 ， 也 包含 了 通过 MOVE 或 者 SHRINK 
操作 减少 表 的 碎片 。 通 过 调整 表 的 存储 结构 可 以 减少 SQL 的 执行 开销 ， 从 而 达到 优化 的 目的 。 
这 种 情况 还 存在 一 个 特例 ， 就 是 通过 调整 表 中 记录 的 顺序 ， 减 少 索 引 的 CLUSTER FACTOR 值 ， 
从 而 达到 降低 索引 范围 扫描 成 本 的 目的 。 在 《Oracle DBA 优化 日 记 》 这 本 书 中 ， 老 白 曾 介绍 过 
一 个 类 似 的 案例 ， 有 兴趣 的 朋友 可 以 查阅 一 下 。 

数据 归档 也 是 最 有 效 的 SQL 优化 方案 之 一 ， 不 过 这 个 方法 常常 被 忽视 。 有 些 SQL 经 常 要 进 
行 全 表 扫 描 或 者 分 区 扫描 ， 对 于 这 类 SQL 来 说 ， 普 通 的 优化 方案 很 难 奏效 ， 如 果 表 中 的 数据 是 
有 时 限 性 的 ， 那 么 设计 历史 数据 查询 功能 ， 定 期 对 生产 数据 进行 归档 ， 就 可 以 控制 这 些 SQL 的 
开销 了 。 
如 果 我 们 在 一 张 包 含 数 千 万 条 记录 的 大 表 中 , 仅仅 查询 其 中 某 几 天 的 数据 , 那么 通过 索引 就 
可 以 很 快 地 完成 查询 ,但 是 如 果 我 们 要 查询 半年 的 数据 , 那么 就 只 能 进行 全 表 扫 描 了 。 对 大 表 进 
行 全 表 扫 描 的 成 本 很 高 ,并且 经 常会 严重 影响 系统 的 性 能 。 如 果 碰 到 这 种 情况 , 我 们 该 如 何 处 理 
呢 ? 由 于 客户 查询 范围 的 不 确定 性 , 我 们 很 难 强制 指定 通过 索引 来 访问 这 张 表 , 不 过 如 果 可 以 限 
定 最 多 只 能 够 查询 3 个 月 的 数据 , 那么 所 有 的 查询 就 都 可 以 通过 索引 来 完成 了 , 这 样 就 能 避免 出 
现 全 表 扫 描 。 虽 然 这 种 限制 对 业务 人 员 来 说 会 有 所 不 便 , 但 是 避免 了 性 能 问题 。 如 果 我 们 在 应 用 
设计 上 考虑 得 更 完善 一 些 , 提供 一 些 能 够 归并 多 次 查询 结果 的 小 工具 , 那么 对 业务 人 员 的 不 便 也 
就 降 到 了 最 小 。 这 一 点 老 白 还 是 和 香港 人 学 的 。 十 多 年 前 , 我 曾 为 香港 某 公 司 外 包 开 发 过 一 个 系 
统 ， 这 个 系统 的 每 个 查询 界面 上 都 设计 了 “归并 查询 ”和 “归并 统计 结果 ”这 样 的 按钮 ， 通 过 这 
些 按钮 可 以 将 一 系列 类 似 的 查询 结果 进行 归并 ， 并 可 以 很 方便 地 调 出 归并 后 的 结果 。 

修改 SQL 是 我 们 最 不 愿意 做 的 事情 ， 不 过 这 也 是 我 们 必须 直面 的 问题 。 当 上 述 方法 都 失效 
时 ， 修 改 SQL 就 不 可 避免 了 。 

老 白 讲 了 半天 , 还 没有 切入 正题 , 大 家 可 能 有 些 着 急 了 。 其 实 不 然 ，SQL 优化 技术 实际 上 并 
不 仅仅 是 抓 住 一 条 SQL, 去 分 析 执 行 计划 这 样 的 体力 活 ， 如果 能 够 四 两 所 千斤 , 谁 还 会 去 傻 费力 
We? 但 既然 是 做 SQL 优化 ， 就 肯定 免不了 要 干 这 种 许 活 、 累 活 。 很 多 DBA 对 于 分 析 SQL 的 
执行 计划 感到 十 分 头痛 ， 其 实 只 要 掌握 了 基本 的 方法 , 这 项 工作 也 并 不 是 什么 难事 ,， 顶 多 算是 比 
较 费 力 的 事情 而 已 。 
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RE, SOL 优化 最 为 关键 的 因素 主要 体现 在 三 个 方面 : 一 是 多 表 连 接 的 顺序 , 二 是 两 个 表 
连接 的 方式 ,三 是 单 表 访问 的 路 径 。 无 论 多 么 复杂 的 多 表 连 接 ， 最 终 都 可 以 落实 到 这 三 点 上 。 实 
际 上 , 如 果 分 析 过 10053 TRACE 文件 就 会 发 现 , 10053 事件 选择 执行 计划 时 也 是 从 这 三 个 方面 来 
考虑 的 。 

在 分 析 复杂 SQL 时 , 首先 要 分 析 SQL 中 每 个 表 的 过 滤 条 件 , 确定 每 个 单 表 的 最 佳 访问 路 径 。 
表 的 访问 路 径 大 体 可 分 为 全 表 扫 描 、 索 引 唯 一 性 扫描 、 索 引 范 围 扫 描 、 快 速 全 索引 扫描 、 索 引 跳 
跃 式 扫描 、 分 区 扫描 等 。 

对 于 每 张 单 表 , 首先 要 根据 表 上 面 的 过 滤 条 件 确定 每 张 表 经 过 过 滤 条 件 后 可 能 产生 的 结果 集 
的 大 小 。 然 后 根据 结果 集 和 表 的 大 小 的 比较 ,我 们 就 可 以 选择 出 合适 的 单 表 访问 路 径 。 这 里 , 通 
过 对 比 表 的 记录 数 和 过 滤 条 件 过 滤 后 的 结果 集 的 大 小 ， 就 能 够 作出 判断 了 。 

对 于 多 表 连 接 , 确定 表 的 连接 顺序 是 最 为 关键 的 , 表 连 接 顺 序 的 选择 要 素 是 尽 可 能 多 地 过 滤 
掉 无 效 的 记录 。 因 此 过 滤 条 件 较 多 的 表 ， 最 终 过 渡 效 果 最 好 的 表 会 排 在 最 前 面 。 

SELECT 


PKG SP SEQ.F E MP P SNAPID, 
B.PRC TACTIC SNAP ID 


FROM 

BF BILL PARA A 

CONSPRC SNAP B, 

CONS SNAP C 
WHERE 
A. TARIFF 1D = B.PRC ID 
AND TRUNC(A. CHG DATE) <= TRUNC(: B5 
AND A. SP ID - B.SP ID 
AND A.CONS 10 - C.CONS ID 
AND B.CALC 1р = С. САС ID 
AND A. АРР NO = B.RELA APP NO 
AND C.APP CODE - :B4 
AND B.ORG NO = :B3 
AND C. ORG NO = 183 
AND A. CALC 10 = -1 
AND NVL(A. CHG DESC, '02') <> '01' 
AND NVL(A.CHG TYP E, '01') <> '02' 


这 条 SQL TE A. B. C 三 张 表 上 都 有 过 滤 条 件 ， 另 外 ，A 和 了 B、B 和 C、A 和 C 都 有 关联 条 
fF. 这 种 情况 是 十 分 复杂 的 , 因为 这 三 张 表 都 可 能 作为 第 一 张 关 联 表 。 如 果 我 们 要 确定 关联 关系 ， 
就 需要 比较 这 几 张 表 上 的 过 滤 条 件 , 判断 哪个 条 件 更 强 。 通 过 分 析 每 张 表 上 的 所 有 过 滤 条 件 过 滤 
后 的 结果 集 的 大 小 ， 就 可 以 找 出 最 佳 的 那 张 表 。 在 这 个 案例 中 是 C 表 ， 这 张 表 上 的 APP_NO + 
ORG. NO 是 很 强 的 过 滤 条 件 ，ORG_NO 是 分 区 主键 ， 经 过 过 滤 后 ， 从 一 张 2000 多 万 条 记录 的 表 
中 筛选 出 了 20 多 条 记录 。 确 定 了 驱动 表 后 ， 就 要 考虑 C 表 的 访问 路 径 了 ， 到 底 是 全 表 扫 描 好 ， 
还 是 按 索 引 扫 描 好 。 这 是 一 张 很 大 的 表 ， 有 2000 多 万 条 记录 ， 全 表 扫 描 肯定 是 不 可 取 的 。 而 符 
合 APP_NO=:B4 条 件 的 记录 大 约 有 200 多 条 ,符合 APP_NO=:B4 AND ORG_NO=:B3 组 合 条 件 的 
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记录 大 约 有 20 多 条 。 因此 可 以 确定 , 如 果 存 在 APP МО+ ОВО М№О 的 索引 , 对 于 这 条 SQL 来 说 ， 
是 最 优 的 。 
由 于 C 表 过 滤 后 只 有 20 多 条 记录 ， 因 此 髓 套 循 环 (nested loop) 可 能 是 较 好 的 选择 ，C 作为 
藤 套 循环 的 驱动 表 。 选 定 了 驱动 表 后 ， 就 需要 分 析 C 表 先 和 哪 张 表 连 接 比 较 好 。 选 择 的 原则 是 ， 
能 够 尽 可 能 多 地 过 滤 掉 数据 , 连接 后 返回 结果 集 较 小 的 优先 考虑 。 这 种 情况 下 ,我 们 可 以 通过 改 
写 SQL， 来 判断 符合 条 件 的 数据 的 数量 ， 比 如 ， 先 来 判断 C+A 连接 的 方式 : 
9ELECT 
Count(*) 
FROM 
BF BILL PARA A 
CONS SNAP C 
WHERE 
TRUNC(A. CHG DATE) <= TRUNC(:B5 ) 
AND A. CONS ID = C.CONS ID 
AND C. APP CODE = : B4 
AND C. ORG NO : B3 
AND А. CALC ID - 1 
AND NVL(A.CHG_DESC, '02') <> 01" 
AND NVL(A.CHG_TYP E, '01') <> "02" 


同样 ， 我 们 也 可 以 分 析 C+B 的 情况 ， 通 过 比较 ， 确 定 一 个 较 好 的 连接 顺序 。 这 样 就 找到 了 
表 连 接 的 顺序 和 表 连 接 的 方式 。 

也 许 我 们 会 面临 更 为 复杂 的 SQL， 包含 了 INLINE View、 子 查询 、CONNECT BY 的 树 状 查 
询 等 ， 不 过 大 多 数 查询 最 终 都 可 以 改写 为 等 价 的 表 连 接 的 方式 。 这 种 情况 下 ， 需 要 首先 将 SQL 
中 的 这 些 内 容 改写 为 等 价 的 表 连 接 ， 然后 再 进行 上 述 案例 中 所 做 的 分 析 。 仅 此 而 已 , 看 上 去 是 不 
是 很 简单 ? 实际 上 ，SQL 优化 也 确实 很 简单 ,其 原理 和 方法 都 是 几 页 纸 就 可 以 说 清楚 的 。 但 是 真 
正 实施 起 来 可 能 就 没有 那么 简单 了 ， 真 正 的 SQL 优化 高 手 都 是 实践 出 来 的 ， 因 此 看 再 多 的 书 ， 
也 不 如 自己 亲手 去 优化 几 个 SQL。 

想 要 成 为 SQL 优化 高 手 的 朋友 们 ， 看 了 本 节 ， 你 们 是 不 是 也 想 去 一 试 身手 了 呢 ? 如 果 是 这 
样 ， 那 还 犹 殉 什么 呢 ， 赶 快 行动 起 来 吧 。 也 许 过 上 一 年 半 载 ， 你 也 可 以 骄傲 地 和 别人 说 ，SQL 
优化 没什么 神秘 的 ， 无 他 ， 唯 手 熟 耳 。 
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在 诊断 问题 时 最 麻烦 的 就 是 某 些 问题 涉及 的 知识 点 很 多 , 这 种 情况 总 是 让 我 们 无 从 下 手 。 此 
时 ,知识 面 的 宽 罕 就 显得 十 分 重要 了 。 最 近 这 儿 年 ,总 是 有 网 友 问 我 一 些 底层 的 核心 问题 。 遇 到 
这 种 情况 ,我 会 很 耐心 地 建议 他 们 先 打 好 基础 ， 在 初学 阶段 不 宜 过 于 深入 地 研究 某 些 问题 ,因为 
Oracle 的 知识 浩如烟海 ， 在 刚 开始 学 习 时 ,我 们 应 该 花 大 量 的 时 间 扩 大 知识 面 ,一味 地 死 抠 条 些 
核心 问题 ， 往 往 得 不 偿 失 。 

如 果 我 们 的 知识 面 够 广 , 那么 磁 到 一 些 故障 时 ， 就 可 以 先 利 用 自己 所 掌握 的 知识 ,缩小 分 析 
范围 ,或 者 将 分 析 要 点 根据 可 能 性 高 低 排序 ， 进行 重点 排查 , 这样 就 可 以 加 快 分 析 的 速度 ,提高 
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解决 问题 的 成 功率 。 

比如 , 一 个 系统 的 某 项 业务 在 每 个 星期 六 早上 总 是 会 短暂 地 挂 起 大 概 一 分 钟 左 右 , BULA 
每 次 挂 起 的 时 间 都 基本 一 样 。 这 种 情况 下 , 我 们 首先 会 想到 是 不 是 当时 系统 资源 出 现 了 不 足 , 但 
通过 操作 系统 监控 进行 分 析 后 ， 排 除了 这 种 可 能 性 。 此 外 ， 操 作 系 统 日 志 也 没有 任何 报错 信息 ， 
这 就 说 明 系 统 本 身 并 不 存在 问题 。 那 么 下 一 个 需要 检查 的 就 是 ALERTLOG 文件 了 , 但 该 文件 也 
没有 任何 问题 。 然 而 , 在 分 析 ASH 数据 时 , 我 们 发 现 当 时 被 挂 起 的 应 用 都 在 等 待 CURSOR:PIN S 
WAITONX 事 件 。 这 时 , 就 需要 我 们 利用 已 掌握 的 知识 来 缩小 问题 的 分 析 范 围 了 。CURSOR:PIN 
S WAIT ON X 等 待 事件 和 共享 池 相 关 , 如 果 我 们 对 这 个 知识 点 理解 得 更 深入 一 些 , 就 会 发 现 这 个 
等 待 事件 从 Oracle 10g 起 才 出 现 ， 并 且 和 互 斥 问题 有 关 ， 是 会 话 执行 SQL 时 访问 游标 产生 的 等 
待 。 如 果 要 分 析 当 前 的 互 斥 等 待 情况， 就 需要 进行 一 次 SYSTEM STATE DUMP 操作 ,但 由 于 我 
们 是 在 分 析 以 前 的 故障 ， 因 此 无 法 进行 采集 。 不 过 我 们 可 以 把 分 析 范 围 限定 在 共享 池 、SGA Jr 
面 ， 接 下 来 就 需要 分 析 共 享 池 或 者 SGA 方面 是 否 存 在 问题 。 通 过 V$SGA_RESIZE_OPS 视图 ， 
我 们 发 现在 故障 出 现 前 后 ， 系 统 出 现 了 大 量 的 RESIZE 操作 ， 主 要 是 共享 池 和 DB Cache 之 间 的 
相互 缩减 。 

接 下 来 ,我 们 继续 分 析 这 个 问题 。 故 障 发 生 时 ， 系 统 并 不 忙 ， 而 是 处 于 从 比较 空闲 转 为 较 忙 
的 中 间 点 上 , 但 在 半 小 时 后 ， 就 进入 高 峰 时 段 了 。 因 此 这 个 时 间 段 也 是 SGA RESIZE 操作 十 分 频 
繁 的 时 段 。 至 此 , 我们 似乎 已 经 找到 了 问题 的 关键 点 ,这 个 故障 可 能 是 由 SGA RESIZE 操作 引起 
的 。 但 如 果 我 们 对 相关 知识 点 十 分 了 解 的 话 ， 就 会 发 现 一 个 疑点 , 这 个 故障 总 是 发 生 在 固定 的 时 
间 点 ， 而 如 果 仅 仅 是 由 于 SGA RESIZE 操作 导致 的 故障 ， 时 间 上 可 能 会 有 些 差别 ， 甚 至 有 时 差异 
会 相当 大 。 于 是 我 们 就 想到 了 另外 一 个 问题 , 到 底 什 么 才 会 导致 周期 性 的 故障 呢 ? 很 可 能 这 个 故 
障 和 某 个 定时 任务 有 关 。 接 下 来 ， 就 需要 检查 所 有 的 调度 (schedule )、 作 业 (job) 和 操作 系统 
的 定时 任务 (crontab )， 凡 是 和 共享 池 抖 动 有 关 的 定时 任务 都 是 需要 重点 分 析 的 对 象 。 在 分 析 过 
程 中 , 我 们 仅仅 发 现 了 一 个 在 这 个 时 间 点 执行 且 可 能 和 共享 池 有 关 的 作业 , 该 作业 在 每 周 六 都 会 
对 一 个 触发 器 进行 重新 编译 , 这 是 因为 该 触发 器 涉及 了 一 项 较为 复杂 的 统计 业务 ,几乎 每 周 触发 
器 的 内 容 都 会 进行 一 些微 调 。 这 个 触发 吉 涉 及 的 表 并 不 是 出 现 故 障 的 那 张 表 , 不 过 通过 共享 池 和 
游标 的 相关 知识 我 们 知道 ， 一 旦 触发 器 修改 ， 那 么 这 张 表 相关 的 游标 都 会 处 于 INVALID 状态 ， 
下 次 执行 时 就 需要 重新 编译 。 这 也 可 能 导致 共享 池 的 争 用 加 剧 , 而 这 时 候 正 是 业务 量 增长 比较 迅 
速 的 时 间 段 ,此 时 出 现 SGA RESIZE 操作 就 是 有 可 能 的 了 。 于 是 我 们 将 这 个 作业 的 执行 时 间 提 早 
了 1 小 时 ， 故 障 就 消失 了 。 

在 这 个 案例 中 , 我 们 不 断 地 使 用 已 掌握 的 知识 缩小 了 分 析 范 围 , 并 逼近 问题 的 根源 。 实 际 上 ， 
最 终 这 个 案例 也 没有 找到 根本 原因 。 不 过 已 经 足够 让 我 们 解决 这 个 问题 了 。 其 实在 我 们 遇 到 的 绝 
大 多 数 案例 中 ， 都 存在 这 样 的 问题 ， 尽 管 最 后 我 们 能 解决 问题 ， 却 无 法 弄 明 白 问 题 的 最 终 原 因 。 

想 要 利用 所 掌握 的 知识 缩小 分 析 范 围 ， 就 必须 对 所 分 析 问 题 涉 及 的 知识 点 掌握 得 十 分 准确 ， 
但 并 不 需要 非常 深入 。 在 上 述 案 例 中 ， 只 要 我 们 能 从 CURSOR:PIN S WAIT X 等 待 联想 到 SGA 
RESIZE 操作 就 已 经 足够 了 ， 并 不 需要 了 人 解 更 深入 的 知识 ， 这 种 情况 下 ， 需 要 的 是 知识 的 广度 而 
不 是 深度 。 如 果 我 们 从 这 个 等 待 事件 入 手 , 深入 分 析 游 标 、 互 斥 这 些 问题 ,那么 就 很 可 能 要 绕 一 
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个 大 弯 才 能 和 某 个 作业 挂 上 钩 , 甚至 在 我 们 深入 研究 了 游标 的 底层 核心 问题 后 , 会 发 现 离 问题 的 
真相 越 来 越 远 了 。 


在 本 节 的 最 后 ， 老 白 要 重申 的 是 ,知识 的 广度 远 比 深度 重要 ， 和 允 有 广度 ， 再 有 深度 才 是 真正 
的 学 习 之 道 。 如 果 一 头 扎 下 去 , 深入 研究 底层 核心 问题 , 很久 后 抬头 一 看 ， 可 能 会 发 现 自己 其 实 


并 没 掌握 什么 有 用 的 知识 。 
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发 现 问题 、 分 析 问 题 、 解 决 问 题 、 总 结 问题 ， 这 是 处 理 问题 的 一 条 正常 路 径 。 我 们 在 分 析 故 
障 时 ， 有 可 能 当时 并 不 能 真正 了 解 问题 的 根源 ， 有 时 候 问题 虽然 解决 了 , 但 是 并 没有 找到 导致 问 
题 的 真正 原因 。 很 多 DBA 处 理 完 案例 后 并 没有 总 结 的 习惯 , 而 是 应 付 完 现场 工作 就 草草 了 事 了 ， 
甚至 如 果 系 统 经 过 重启 后 问题 解决 了 ， 也 就 不 再 过 问 其 他 的 事情 了 。 

这 种 习惯 其 实 是 很 不 好 的 。 一 方面 问题 的 原因 没 找到 ,下 一 次 发 生 类 似 故障 的 几率 很 大 ; 另 
一 方面 ， 这 也 不 利于 自身 能 力 的 提高 。 对 于 每 个 问题 ， 只 要 还 没有 找到 真正 的 原因 ,那么 这 个 问 
题 就 应 该 还 处 于 开启 状态 , 不 能 关闭 。 这 也 就 意味 着 我 们 还 必须 继续 分 析 这 个 问题 ， 直 到 有 充分 
的 理由 可 以 关闭 该 问题 为 止 。 

EAE FABAS, 一 个 问题 如 果 在 最 近 的 两 个 月 内 没有 重 现 , 那么 这 个 问题 的 重要 性 也 就 没 那 
么 高 了 , 而 且 如 果 两 个 月 内 我 们 都 没 能 关闭 这 个 问题 , 就 说 明 该 问题 可 能 不 在 我 们 处 理 的 能 力 范 
围 之 内 ， 或 者 缺少 某 些 诊断 资源 ,无 法 进一步 分 析 。 因 此 老 白 通常 将 问题 强制 关闭 的 时 间 设 定 为 
两 个 月 ， 对 于 尚未 关闭 的 问题 ,在 两 个 月 内 一 定 要 进一步 分 析 ， 哪怕 事情 再 忙 ， 也 要 抽出 时 间 来 
完成 。 如 果 缺 少数 据 ， 可 能 还 需要 客户 协助 补充 。 但 如 果 某 个 问题 在 两 个 月 后 ,还 没有 任何 实质 
性 的 进展 , 那么 就 可 以 暂时 关闭 该 问题 了 , 因为 精力 和 资源 有 限 , 让 那么 多 问题 都 处 于 开启 状态 ， 
可 能 会 让 我 们 疲于奔命 。 表 15-1 是 老 白 使 用 的 问题 登记 表 。 


表 15-1 
问题 类 别 客户 名 称 АЖЕ 关闭 时 间 关闭 类 别 故障 描述 故障 分 析 相关 资料 位 置 


对 于 那些 已 关闭 的 问题 , 我 们 可 以 在 半年 或 者 一 年 后 进行 回顾 ,因为 在 这 段 时 间 里 可 能 处 理 
了 一 些 类 似 的 案例 或 者 某 方面 的 能 力 得 到 了 提升 , 那么 以 前 觉得 棘手 的 问题 ,此 时 也 许 很 容易 就 
能 解决 了 。 

定期 回顾 案例 是 很 好 的 做 法 ， 有 助 于 提升 自己 的 能 力 。 老 白 每 次 写 书 时 ， 都 会 回 过 头 去 翻 看 
大 量 以 前 做 过 的 案例 ， 从 中 挑选 一 些 作 为 写作 的 素材 。 这 种 回顾 对 老 白 来 说 是 受益 无 穷 的 。 在 翻 
看 时 , 老 白 会 发 现 一 些 自己 十 分 满意 的 案例 ,其 中 包含 很 多 值得 探讨 的 内 容 ， 而 另外 一 些 案例 只 
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是 表面 上 解决 了 问题 ， 但 其 实 当时 并 没 能 抓 住 问题 的 实质 ， 解 决 问题 仅仅 是 运气 而 已 。 

男 外 ,我 们 还 应 该 创建 自己 的 问题 处 理 档案 , 并 建立 闭环 管理 制度 , 给 自己 制定 一 个 问题 关 
闭 的 期 限 , 这 样 有 助 于 深入 地 分 析 、 总 结 问题 。 同 时 ， 定 期 回顾 机 制 也 可 以 进一步 提升 自己 的 能 
Jj, 并 提供 更 多 的 学 习 途 径 。 因 此 老 白 建议 大 家 ,无 论 能 力 如 何 , 都 应 尽快 建立 一 套 适合 自己 的 
案例 管理 机 制 。 


15.7 灵活 运用 你 的 知识 


Oracle RDBMS 是 十 分 复杂 的 系统 , 我 们 不 能 只 依靠 简单 的 原理 来 处 理 RDBMS 的 系统 问题 。 
很 多 DBA 都 热衷 于 掌握 一 些 特别 简单 实用 的 原则 ， 比 如 DB Cache 的 命中 率 不 能 低 于 90%, Н 
志 切 换 的 时 间 不 能 小 于 15 分 钟 等 。 但 实际 上 ， 在 掌握 这 些 原 则 的 同时 ， 也 陷 人 了 一 个 罗 生 门 。 
尽管 这 些 知 识 对 于 分 析 数 据 库 是 有 帮助 的 , 我 们 也 可 以 通过 这 些 知 识 对 数据 库 制 定 定量 的 分 析 准 
则 ， 但 如 果 不 能 灵活 应 用 ， 就 可 能 会 带 来 很 多 不 利 的 影响 。 

在 简单 的 环境 中 ,， 某 些 原 则 可 能 很 容易 发 挥 作用 ， 比 如 , 我们 不 考虑 其 他 的 因素 , 单 从 日 志 
切换 对 系统 造成 的 影响 来 看 ， 过 于 频繁 的 日 志 切 换 肯定 对 系统 不 利 ， 是 应 该 尽 可 能 避免 的 。 但 是 
有 些 情况 下 ， 这 个 原则 可 能 会 起 反作用 。 

前 些 年 ,我 们 给 一 个 客户 做 巡 检 , 每 三 个 月 一 次 。 我 第 一 次 到 现场 时 就 发 现 这 个 系统 的 日 志 
量 很 大 ,几乎 20 多 秒 就 会 切换 一 个 日 志 ， 而 日 志文 件 的 大 小 是 100 MB。 这 种 设置 明显 是 很 不 合 
理 的 , 但 我 并 没有 马上 下 结论 , 而 是 分 析 了 日 志 切 换 可 能 给 系统 带 来 多 大 的 影响 ,经 过 分 析 发 现 ， 
LOG FILE SWITCH 事件 的 等 待 时 间 很 短 ， 而 且 占 整个 系统 的 等 待 比 重 并 不 高 ， 只 有 不 到 196, 
这 就 说 明 目 前 的 日 志 切 换 频率 并 没有 对 系统 产生 较 大 的 影响 。 男 外 ，CF 锁 所 占 的 等 待 比 重 也 不 
高 ， 说 明日 志 切 换 并 没有 对 CF 锁 造 成 太 大 的 影响 。 目 前 这 个 系统 存在 一 个 本 地 DATAGUARD , 
一 个 远程 DATAGUARD (通过 日 志 以 手工 压缩 传输 方式 完成 ) 和 一 个 逻辑 DATAGUARD， 从 这 
种 配置 来 看 , 较 小 的 日 志文 件 还 是 对 这 些 DATAGUARD 有 些 帮 助 的 。 于 是 我 建议 客户 维持 现状 ， 
暂时 不 要 扩大 日 志文 件 。 

一 年 后 ， 这 个 系统 的 REDO LOG 量 持续 增长 , 日志 切 换 的 间隔 进一步 缩小 ，CF 锁 等 待 和 
LOG FILE SWITCH 等 待 的 平均 等 待 时 间 也 在 不 断 增长 。 在 这 种 情况 下 ， 生 产 库 因 为 日 志文 件 过 
小 而 出 现 故障 的 概率 也 在 不 断 增 长 .尽管 DATAGUARD 仍然 存在 ,但 是 我 们 必须 加 大 REDO LOG 
文件 ， 从 而 确保 生产 库 的 正常 运行 。 虽然 基础 环境 并 没有 变化 ， 但 这 时 对 REDO LOG 文件 做 出 
调整 和 一 年 前 保持 文件 大 小 不 变 ， 同 样 都 是 正确 的 。 

KEEA, 大 道 无 形 。 优 化 也 是 一 样 ， 实 施 者 需要 具备 广博 的 知识 ， 知 识 面 越 广 ， 越 能 够 在 
纷繁 的 头绪 中 选取 最 佳 的 技术 路 线 。 也 许 这 样 说 对 很 多 DBA 要 求 太 高 了 ， 但 是 经 验 和 知识 需要 
积累 ， 不 是 看 几 本 书 就 可 以 实现 的 。 确 实 ， 我 最 近 在 写 DBA 日 记 时 翻阅 了 很 多 几 年 前 的 文档 ， 
发 现 以 前 在 处 理 很 多 案例 的 时 候 , 都 犯 了 不 少 的 错误 , 起 码 处 理 得 不 够 圆满 , 可 能 做 这 一 行 久 了 ， 
看 东西 就 变 得 苛刻 起 来 了 。 

一 个 人 不 可 能 是 全 才 , 不 可 能 无 所 不 知 ， 犯 错误 是 难免 的 , 但 掌握 的 知识 多 一 些 ， 犯 错误 的 
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机 率 就 会 变 小 。 去 年 给 一 个 客户 做 优化 ， 当 时 看 到 系统 都 使 用 了 绑 定 变量 ,所 以 觉得 大 不 了 就 用 
存储 概要 (stored outlines ) 来 解决 执行 计划 的 问题 。 但 到 了 最 后 ， 问 题 真 的 来 了 ， 优 化 后 绝 大 多 
数 模 块 的 性 能 都 提高 了 数 倍 ， 只 有 一 个 模块 性 能 下 降 了 50% 多 。 经 过 检查 发 现 , 是 一 张 表 和 一 个 
视图 做 连接 ,优化 器 无 法 主动 进行 视图 合并 ， 导致 这 个 模块 性 能 下 降 。 后 来 经 过 手工 测试 ,添加 
合并 提示 后 性 能 问题 就 解决 了 。 但 当时 我 没有 想到 这 个 提示 居然 无 法 通过 存储 概要 合并 。 无 奈 之 
F, 我 只 能 将 相关 数据 压缩 并 发 送 , 希望 印度 朋友 能 帮忙 解决 , 但 最 终 也 没 能 得 到 回应 , 于 是 自 
己 找 来 一 份 文档 , 才 了 解 到 合并 是 无 法 通过 存储 概要 添加 的 。 我 通过 这 个 项 目 长 了 学 问 , 但 也 被 
折腾 得 够 哈 。 最 后 经 过 一 番 软 磨 硬 泡 ,客户 才 接 受 了 那个 模块 性 能 必须 下 降 的 结果 ,至 此 ,终于 
了 结 了 这 个 项 目 。 我 想 今后 再 去 实施 类 似 的 项 目 时 ， 就 会 多 一 个 心眼 了 。 

有 一 次 ， 和 几 个 网 友 讨论 存储 概要 的 问题 , 一 位 朋友 问 道 , 为 什么 不 使 用 SQL PROFILE 呢 ， 
这 对 优化 SQL 不 是 更 有 效 ? 确实 在 绝 大 多 数 情况 下 ，SQL PROFILE 更 为 有 效 ， 但 真 的 碰 到 一 些 
不 太 可 能 发 生 的 少数 情况 时 , 存储 概要 可 能 会 比 SQL PROFILE 更 适合 。 优化 无 定式 , 合适 就 好 。 

算 起 来 ， 从 第 一 次 给 客户 优化 系统 到 现在 已 经 10 多 年 了 。 在 这 些 年 里 ， 接 触 过 不 同 的 客户 
和 系统 ， 对 于 优化 工作 的 体会 也 越 来 越 深 刻 。 刚 开始 做 优化 时 ， 总 是 希望 找 出 系统 中 所 有 存在 问 
题 的 地 方 , 然后 逐个 进行 调整 。 由 于 对 Oracle 的 基本 原理 认识 不 够 , 并 且 对 优化 的 认识 也 仅 限 于 
调整 不 合理 部 分 的 浅 层次 上 , 因此 经 常会 遇 到 一 些 事 与 愿 违 的 情况 。 实 际 上 ， 进 行 优 化 工作 时 需 
要 灵活 运用 知识 。 首 先 ， 优 化 是 基于 目标 的 ,我 们 的 最 终 目的 是 达到 这 个 目标 ， 而 不 是 做 优化 。 
其 次 ， 目 标的 合理 性 决定 了 优化 项 目的 成 败 。 刚 开始 从 事 优化 工作 时 , 我 会 将 所 有 能 够 调整 的 问 
题 一 次 性 处 理 完毕 ， 即 使 有 些 调整 给 系统 性 能 带 来 的 好 处 只 有 不 到 0.1%。 生 产 系 统 的 不 确定 因 
素 很 多 ， 而 一 些 参数 方面 的 调整 本 身 就 是 双 刃 剑 ， 如 果 无 法 预期 其 带 来 的 影响 , 那么 这 种 调整 就 
是 存在 风险 的 , 在 实施 的 时 候 就 应 该 慎重 考虑 。 现 在 我 再 做 优化 项 目 时 , 往往 会 根据 用 户 的 优化 
目标 进行 分 析 ， 并 在 此 基础 上 制定 方案 ,实施 的 结果 一 般 都 会 超出 客户 的 期 望 , 但 是 我 不 会 在 生 
产 系统 上 进行 一 些 没 把 握 的 调整 。 锦 上 添 花 的 事情 有 时 候 是 需要 慎重 考虑 的 , 弄 不 好 就 会 变 成 画 
蛇 添 足 。 这 种 情况 下 ,需要 针对 具体 问题 进行 分 析 ， 不 应 拘泥 于 某 个 知识 点 ， 而 应 将 所 掌握 的 知 
识 灵 活 运用 到 实际 的 优化 工作 中 。 比 如 , 我 们 经 常 被 教导 ，SQL 一 定 要 使 用 绑 定 变量 , 这 句 话 在 
绝 大 多 数 场合 是 对 的 ， 但 在 某 些 场合 却 不 一 定 正 确 。 在 10g 数据 库 中 ， 如 果 某 个 字段 是 倾斜 的 ， 
由 于 柱状 图 的 存在 ， 可 能 不 使 用 绑 定 变量 会 更 好 一 些 。 可 能 有 些 朋 友 会 说 , 在 11g 版 本 中 ， 随 着 
ACS 技术 的 出 现 ， 是 不 是 就 可 以 放心 地 使 用 绑 定 变 量 了 呢 ? 是 的 ， 在 绝 大 大 数 情 况 下 确实 如 此 ， 
不 过 老 白 也 碰 到 过 一 种 情况 ， 尽 管 ACS 已 经 发 挥 了 作用 ， 但 在 一 个 游标 下 还 是 产生 了 大 量 不 可 
共享 的 子 游标 ， 这 导致 CURSOR:PIN S WAIT X 等 待 十 分 严重 。 最 后 取消 了 绑 定 变 量 ， 才 解决 了 
这 个 问题 。 

另外 需要 注意 的 一 点 是 ,“1+1” 其 实 并 不 一 定 大 于 1。 在 处 理 问 题 的 过 程 中 ,应 抓 住 主要 矛 
盾 ， 解 决 主要 问题 ， 而 不 是 胡子 眉毛 一 把 抓 。 很 多 调整 之 间 都 存在 关联 性 ， 甚 至 是 互 斥 的 ,不合 
理 的 调整 可 能 带 来 更 糟 的 结果 。 这 也 需要 我 们 灵活 运用 所 学 的 知识 ,而 不 能 墨守成规 。 在 大 多 数 
情况 下 ， 如 果 CPU 使 用 率 接近 100%， 那 么 加 大 DB Cache 就 很 可 能 会 导致 更 严重 的 CPU 争 用 ， 
但 是 这 也 不 是 绝对 的 。 老 白 就 碰 到 过 一 个 类 似 的 案例 ,通过 分 析 发 现 , 由 于 某 个 查询 相关 的 一 张 
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表 的 数据 存放 在 VO 能 力 较 差 的 文件 上 ， 而 此 时 VO 的 整体 性 能 也 不 佳 ， 平 均 单 块 读 操 作 响应 时 
间 达 到 11 毫秒 ， 这 使 得 这 条 SQL 的 执行 时 间 从 0.01 秒 上 升 为 0.1 秒 ， 从 而 导致 了 大 量 的 查询 积 
压 ， 提 高 了 CPU 的 使 用 率 。 通 过 加 大 DB Cache， 提 高 了 VO 的 整体 响应 时 间 ， 这 条 SQL 的 平均 
执行 时 间 从 0.1 秒 下 降 为 0.04 秒 ， 查 询 积 压 消 除了 ，CPU 使 用 率 恢复 到 80% 左 右 。 

不 要 相信 什么 规则 , 实际 上 , 并 没有 条 条 框框 的 限制 , 任何 实现 目标 的 方法 都 是 可 以 使 用 的 。 
对 于 一 个 初级 DBA 来 说 , 老 DBA 可 能 会 告诉 你 , 什么 是 对 的 , 什么 是 不 对 的 。 而 对 错 原本 就 是 
相对 的 , 如 果 已 经 深刻 地 理解 了 Oracle 以 及 系统 优化 的 原理 , 那么 就 可 以 像 金 庸 小 说 里 的 内 功 高 
手 一 样 ， 无 招 有 性 有 招 ， 进 入 到 更 高 层次 的 自由 发 挥 境界 。 
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Oracle 的 数据 库 技 术 发 展 很 快 ， 这 一 点 对 于 每 个 DBA 来 说 ， 都 是 既 痛苦 又 幸福 的 事情 。 最 
近 这 10 多 年 ，Oracle 公司 基本 上 以 每 5 年 一 个 新 版 本 的 速度 进行 更 新 。 记 得 2004 年 在 做 一 个 优 
化 项 目 时 ， 还 和 几 个 搭档 讨论 过 Oracle 发 展 的 问题 ， 其 中 一 个 人 说 他 已 经 从 7.0 T 8i Т, 8i 
也 许 就 是 他 学 习 的 最 后 一 个 版 本 了 ， 绝 对 不 会 再 学 9 了 。 不 过 没 多 久 ， 我 们 又 接 了 一 个 9i 的 优 
化 项 目 ， 于 是 我 看 到 他 房间 里 又 多 了 几 本 9i 的 书籍 。 这 回 他 再 次 向 我 发 拆 ，9%i 将 是 他 职业 生涯 
中 学 习 的 最 后 一 个 版 本 ， 坚 决 不 接触 10g。 不 过 这 个 誓言 后 来 义 变 成 了 11g， 这 回 他 没有 再 次 食 
言 ， 因 为 他 彻底 改行 了 ， 去 一 家 电 商 网 站 做 起 了 CIO. 

每 $ 年 更 新 一 个 版 本 ， 这 对 DBA 提出 了 很 大 的 挑战 。Oracle 技术 发 展 得 如 此 之 快 ， 这 意味 

着 已 经 约定 俗 成 的 一 些 概念 和 技巧 很 快 就 会 过 时 。 如 果 DBA 总 是 以 老 观念 来 面 对 新 的 数据 库 ， 
那么 肯定 会 有 问题 的 。 我 经 常 在 网 络 上 和 一 些 朋 友 进 行 沟 通 , 发 现 他 们 经 常会 提 到 的 一 些 网 络 上 
的 文章 ， 而 文章 中 提出 的 一 些 观点 ， 以 及 用 到 的 一 些 技术 ， 都 是 很 早 以 前 8.0 时 代 的 技术 ， 甚 至 
有 些 是 基于 7.0 数据 库 的 。 有 些 知 识 已 经 严重 过 时 了 , 甚至 有 些 观 点 放 到 现在 的 102. 11g 环境 中 
已 经 是 错误 的 了 。 
在 10 多 年 前 ， 那 时 候 的 硬件 资源 十 分 昂贵 ，32 位 的 系统 是 主流 系统 ， 因 此 系统 配置 往往 很 
低 。 对 于 DBA 来 说 ， 优 化 的 重点 是 如 何 协调 使 用 这 些 系 统 资源 ， 使 之 能 够 达到 一 个 比较 优化 的 
平衡 点 ,因此 各 种 辊 转 腾挪 的 小 技巧 被 使 用 到 了 极致 ,最 典型 的 示例 就 是 基于 共享 池 的 优化 操作 ， 
那 时 的 DBA 必须 熟练 掌握 共享 池 的 优化 技术 。 哪 怕 有 几 个 参数 没有 设置 妥当 ， 都 可 能 导致 十 分 
严重 的 性 能 灾难 ， 甚 至 出 现 宕 机 的 故障 。 

那 时 候 数据 库 的 主流 版 本 是 8.0 和 8i， 大 多 数 服务 器 只 配备 了 4~8 GB 的 物理 内 存 和 2~4 
个 CPU, 一 般 来 说 ， 共 享 池 也 只 有 100 MB ~ 1GB，500 MB 的 共享 池 配 置 已 经 算是 比较 大 的 了 。 
由 于 共享 池 容 量 较 小 ， 因 此 ， 一 旦 共享 池 出 现 争 用 ， 将 会 导致 十 分 严重 的 后 果 。 


Cache Sizes 


db_block_buffers: 186432 log_buffer: 3145728 
db block size: 8192 shared pool size: 681574400 


上 面 是 一 个 典型 的 8i 数 据 库 的 CACHE 配置 ,这 套 系统 是 一 个 电信 的 计 费 系统 ,配置 了 650 MB 
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的 共享 地 和 6144 MB 的 DB Cache， 这 在 当年 也 算是 非常 大 的 系统 了 。 对 于 这 样 的 系统 ， 如 果 每 
秒 存在 几 百 个 SQL 解析 ， 那么 共享 池 就 会 受到 很 大 的 冲击 ,一 旦 某 些 配置 不 合理 ,或 者 业务 高 
峰 时 对 某 些 存储 过 程 、 视 图 进行 了 编译 ， 就 可 能 导致 共享 池 出 现 严 重 的 性 能 故障 。 因 此 在 Si 时 
代 ， 共 享 池 中 的 参数 设置 需要 十 分 精细 ， 而 一 般 的 优化 项 目 也 会 将 共享 池 的 优化 工作 作为 重点 。 
在 这 种 情况 下 ， 使 用 绑 定 变量 、 调 整 CURSOR_SHARING , OPEN CURSORS 、 
SESSION CACHED CURSORS 等 参数 就 会 变 得 十 分 关键 。 记 得 10 多 年 前 我 曾 优化 过 一 套 8; 的 
系统 ,多数 情 况 下 系统 运行 正常 , 但 有 时 会 变 得 非常 慢 ， 甚 至 会 出 现 几 乎 无 法 工作 必须 强制 重启 
的 情况 。 而 且 这 种 情况 没有 什么 规律 ,在 业务 高 峰 的 月 底 、 月 初 都 没 问 题 ， 而 业务 最 闲 的 月 中 反 
而 经 常 出 问题 。 客 户 找 了 很 多 公司 帮忙 ,甚至 原 厂 都 去 了 很 多 次 , 但 一 直 没 能 解决 问题 。 当 我 找 
到 问题 的 原因 向 他 们 汇报 时 , 大 家 都 感到 有 些 啼笑 皆 非 ,原来 是 系统 中 的 一 个 应 用 采用 了 短 连接 
方式 , 经 常会 由 于 大 量 的 LOGON/LOGOFF 操作 导致 共享 池 出 现 问题 。 之 前 ，Oracle 公司 的 工程 
师 曾 建议 对 这 部 分 应 用 使 用 共享 服务 器 模式 ， 自 从 使 用 了 该 模式 后 ,系统 变 得 稳定 了 。 这 是 一 个 
不 错 的 优化 操作 ,使 用 共享 服务 器 模式 减少 了 进程 启动 和 关闭 的 开销 , 使 得 系统 更 为 稳定 , 但 随 
着 这 个 应 用 业务 量 的 增长 ， 共 享 服务 器 模式 的 会 话 对 大 型 池 ( large pool) 的 需求 也 在 不 断 增 长 ， 
当 大 型 池 不 足 时 ,问题 就 出 现 了 。 这 部 分 应 用 变 慢 会 导致 其 对 共享 池 中 其 他 对 象 的 PIN 时 间 变 长 ， 
从 而 产生 连锁 反应 ， 导 致 共享 池 争 用 越 来 越 严重 ， 并 最 终 出 现 问 题 。 找 到 了 问题 的 原因 ， 解 决 起 
来 就 很 容易 了 ， 只 需 将 大 型 池 从 100 MB 调整 到 200 MB， 这 个 问题 就 解决 了 。 当 时 我 还 特意 嘱 
咯 客 户 ， 由 于 目前 内 存 有 限 ,无 法 将 大 型 池 设 置 得 太 大 ， 如 果 业 务 量 还 在 不 断 扩大 ,那么 过 一 段 
时 间 共 享 池 可 能 还 会 不 足 ， 一定 要 注意 监控 。 

这 个 问题 如 果 放 到 现在 就 很 好 解决 了 , 在 物理 内 存 十 分 廉价 的 今天 , 一 台 微 机 服务 器 往往 都 
可 以 配置 几 十 GB 甚至 几 百 GB 的 物理 内 存 ， 随 便 给 共享 池 分 配 500 MB 的 内 存 ， 就 万 事 大 吉 了 。 
随 着 内 存 价格 的 不 断 下 降 ， 拥 有 大 内 存 、 大 量 CPU 的 服务 器 已 经 不 再 是 奢望 了 。 在 近 些 年 的 优 
化 项 目 中 , 我 经 常 通过 设置 足够 大 的 共享 池 来 解决 一 些 问题 , 甚至 有 些 问题 都 没有 进行 特别 深入 
的 分 析 ， 只 分 析 了 其 浅 层 的 问题 原因 ， 而 这 些 调整 往往 都 是 立竿见影 的 。 起 初 客 户 还 有 些 担心 ， 
特别 是 在 8i 时 代 ， 一般 的 共享 池 配 置 都 是 几 百 MB ， 而 在 那个 时 候 ， 我 就 经 常 在 一 些 64 位 的 系 
统 上 配置 大 共享 池 。 

有 一 次 , 我 在 做 一 个 优化 项 目 时 ,建议 客户 将 共享 池 从 512 MB 调整 到 2GB。 客户 本 身 也 是 
一 名 资深 的 DBA， 他 对 共享 池 的 结构 非常 清楚 ， 对 这 项 调整 感到 十 分 担忧 。8&: 的 FREELIST H 
有 10 多 个 BUCKET, 那么 大 的 内 存 挂 在 几 个 列表 上 ， 会 不 会 导致 FREELIST 争 用 ， 从 而 影响 性 
能 呢 ? 其 实 这 也 是 当时 很 多 DBA 所 担心 的 ， 甚 至 有 些 观点 认为 共享 池 设 置 过 大 会 严重 影响 系统 
的 性 能 。 确 实 ， 将 共享 池 设置 得 过 大 ， 是 有 可 能 引起 严重 的 性 能 问题 ， 这 种 案例 在 10 多 年 前 也 
比比 皆 是 。 不 过 这 些 故 障 都 是 有 前 提 的 ， 那 是 在 基于 很 高 的 并 发 量 、 较 小 的 系统 资源 ， 特 别 是 
CPU 已 经 出 现 了 瓶颈 的 情况 下 发 生 的 。 而 我 当时 面 对 的 这 个 案例 不 同 ， 虽 然 客 户 使 用 的 还 是 Si 
版 本 , 但 是 系统 的 物理 内 存 有 48GB, CPU 也 有 244, CPU 资源 是 十 分 充足 的 , 在 这 种 情况 下 ， 
较 大 的 共享 池 的 作用 是 正面 的 ， 其 负面 影响 几乎 可 以 忽略 。 事 实证 明 , 调整 了 共享 池 后 ， 系 统 变 
得 十 分 稳定 ， 这 次 优化 是 成 功 的 。 
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在 这 个 案例 中 ， 之 前 的 好 几 个 DBA 都 曾经 尝试 对 系统 进行 优化 ， 也 都 发 现 了 共享 池 不 足 给 
系统 带 来 了 很 大 的 影响 , 都 在 试图 减少 应 用 对 共享 池 的 使 用 。 不 过 在 应 用 架构 不 能 够 修改 的 情况 
F, 这些 努力 收效 甚 微 。 他 们 也 曾经 试图 加 大 共享 池 ， 但 是 并 不 敢 将 共享 池 设 置 得 过 大 ， 曾 经 有 
一 个 DBA 将 这 个 系统 的 共享 池 从 512 MB 加 大 到 800MB ， 但 没有 收 到 明显 的 效果 ， 于 是 又 回 退 
了 。 他 们 为 什么 会 失败 ， 而 老 白 却 能 够 成 功 呢 ? 这 是 因为 他 们 并 没有 综合 分 析 问 题 的 根源 ， 而 是 
被 以 往 的 案例 和 大 家 普遍 认可 的 “相对 真理 ”所 束缚 了 。 因此 在 调整 共享 池 这 个 问题 上 说 小 慎 微 ， 
不 敢 大 胆 突破 。 老 白 并 没有 被 那些 所 谓 的 专家 观点 、 历 史 教训 所 束缚 ， 而 是 从 本 质 上 分 析 了 以 往 
设置 较 大 共享 池 导 致 性 能 下 降 的 案例 ,其 中 大 多 数 都 是 由 于 CPU 资源 存在 瓶颈 ， 共 享 池 变 大 后 ， 
并 发 量 的 增加 导致 了 共享 池 门 锁 争 用 加 剧 ， 从 而 使 得 CPU 资源 消耗 更 大 ， 并 最 终 导致 了 性 能 问 
题 。 基 于 这 样 的 分 析 ， 老 白 认为 在 CPU 资源 能 够 得 到 保证 的 前 提 下 ， 使 用 较 大 的 共享 池 是 可 行 
的 ， 因 此 才能 够 大 胆 地 将 共享 池 从 512 MB 加 大 到 2 GB. 

从 第 一 个 大 型 优化 项 目 开 始 算 起 , 老 白 从 事 Oracle 性 能 优化 工作 也 差不多 有 10 年 的 时 间 了 ， 
在 这 10 年 中 ,优化 的 重点 和 方法 在 不 断 地 变化 。 现 在 回 过 头 来 看 10 年 前 的 一 些 项 目 资料 ,我 发 
现 很 多 优化 技术 都 已 经 有 些 陌生 了 。 在 10 多 年 前 ， 回 滚 段 的 优化 是 十 分 重要 的 ， 特 别 是 在 电信 
计 费 这 类 变更 十 分 频繁 的 系统 中 。 在 7.0、8.0 Si 时 代 ， 大 型 计 费 系统 的 优化 都 离 不 开 回 滚 段 
的 优化 。 设 置 合适 的 回 滚 段 数量 以 及 OPTIMAL SIZE 参数 值 ， 都 是 十 分 重要 的 ， 甚 至 每 个 扩展 
的 大 小 都 可 能 成 为 系统 故障 的 元 多。 那个 年 代 的 DBA， 都 掌握 一 个 技巧 ， 就 是 必须 在 每 个 系统 
中 留 出 几 个 较 大 的 回 滚 段 , 作为 处 理 大 事务 的 专用 回 滚 段 。 一 旦 要 对 计 费 数据 进行 较 大 的 更 新 操 
作 ， 就 必须 指定 使 用 这 些 大 回 滚 段 。 和 否则 就 可 能 出 现 SQL 执行 了 10 多 个 小 时 后 ， 由 于 回 滚 段 不 
足 而 失败 。 

即便 如 此 小 心地 优化 回 滚 段 ，ORA-1555 错误 仍然 是 一 个 十 分 考验 DBA 技巧 的 问题 。 记 得 
ЖШ DBA 面试 的 时 候 ， 如 果 某 个 应 聘 人 员 能 够 很 圆满 地 回答 如 何 解决 ORA-1555 的 问题 ， 那 么 
他 被 录用 的 机 会 就 很 大 了 。 有 不 少 DBA 靠 着 这 一 招 ， 就 可 以 “混迹 江湖 ”了 。 

不 过 随 着 9i 版 本 的 出 现 ， 这 些 技术 都 变 得 无 用 了 。 这 让 很 多 老 DBA РУЧНЕ, “ME 
的 年 轻 人 只 会 设置 UNDO. RETENTION 参数 , 连 专 用 回 滚 段 都 不 知道 "， 这 种 观点 其 实 只 是 酸 葡 
萄 心理 而 已 。 既 然 有 了 UNDO 自动 管理 ， 为 什么 还 要 回 过 头 去 使 用 复杂 的 手工 管理 模式 呢 ? 虽 
然 在 某 些 极端 情况 下 ，UNDO 手工 管理 还 有 一 定 的 作用 , 但 在 一 般 情 况 下 , 我 们 可 以 放心 大 胆 地 
去 使 用 UNDO 自动 管理 。 

在 以 前 的 一 个 优化 项 目 中 ,客户 的 DBA 曾 问 我 ， 现 在 默认 的 UNDO 空间 只 有 40 GB ， 如 果 
不 够 用 怎么 办 。 我 告诉 他 ， 那 就 给 它 开 200 СВ. 10 多 年 前 我 们 在 小 心 谨慎 地 优化 回 滚 段 时 ， 经 
常 为 了 能 腾 出 1~2GB 的 空间 给 某 个 RBS 而 和 煞费苦心， 而 现在 一 块 大 点 的 硬盘 都 有 2TB 的 容量 
T, JLA GB 的 存储 空间 简直 是 手 到 擒 来 的 事情 。 在 这 种 情况 下 ， 我 们 有 什么 理由 不 给 UNDO 
多 分 配 一 些 空间 呢 ? 

如 果 DBA 不 能 与 时 俱 进 ， 还 守 在 一 些 陈 芝麻 烂 谷子 里 面 过 日 子 ， 那么 可 以 预见 ， 他 们 必然 
会 付出 大 量 的 劳动 ， 而 只 能 收获 很 小 的 成 果 。Oracle 这 些 年 在 技术 上 的 进步 是 巨大 的 ,确实 如 拉 
里 所 说 ，Oracle 10g 是 一 个 充分 自 管理 的 数据 库 ，DBA 应 该 充分 利用 这 些 新 特性 , 将 自己 从 一 些 
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繁杂 的 事情 中 解脱 出 来 ， 去 考虑 更 需要 投入 精力 的 问题 。 

老 白 曾经 不 止 一 次 说 过 , 使 用 10g 数据 库 而 不 用 EM 管理 器 是 极 大 的 浪费 。 确 是 如 此 ， 这些 
年 10g 版 本 的 应 用 已 经 十 分 普及 了 ， 但 事实 上 2011 年 就 已 经 进入 了 10g 的 延长 维 保 期 ，Oracle 
会 很 快 停止 对 10g 版 本 的 支持 ,可 能 大 规模 迁移 到 11g 就 是 最 近 一 两 年 的 事情 了 。 而 绝 大 多 数 的 
DBA 还 在 用 9i 的 方式 管理 着 10g 的 数据 库 ， 还 抱 着 一 堆 脚 本 不 放 ， 用 陈旧 落后 的 手段 维护 着 自 
己 的 系统 。10g 数据 库 中 一 个 十 分 耀眼 的 新 特性 就 是 其 新 的 管理 基础 架构 ， 这 个 基础 架构 是 构建 
自 管理 数据 库 的 核心 ， 而 EM 管理 器 和 该 基础 架构 的 集成 十 分 紧密 ， 通 过 EM 管理 需 来 使 用 10g 
版 本 的 新 管理 特性 是 最 为 简便 的 方法 。 

11g 版 本 在 这 方面 走 得 更 远 ， 它 是 一 个 充分 仪表 化 的 数据 库 ， 我 们 可 以 在 Oracle 的 管理 框架 
中 更 为 便捷 地 管理 数据 库 。 这 对 于 还 没有 习惯 使 用 图 形 界面 的 DBA 来 说 ， 是 一 个 更 大 的 挑战 。 

在 本 节 的 最 后 ， 老 白 再 一 次 呼吁 广大 DBA， 现 在 是 据 弃 固有 的 成 见 ， 与 时 俱 进 、 勇 敢 接触 
新 技术 的 时 候 了 ; 现在 是 放下 手头 的 脚本 ， 看 着 图 形 化 仪表 来 管理 数据 库 的 时 候 了 。 


15.9 多 表 连 接 的 优化 技巧 


如 果 一 个 系统 突然 变 慢 ， 并 且 AWR 报告 中 某 条 SQL 的 BUFFER GET 很 高 ， 那 么 我 们 就 需 
要 使 用 AWRSQRPT 脚本 生成 一 个 SQL 报告 。 此 时 我 们 会 发 现 ， 出 现 问题 的 是 一 条 十 分 复杂 的 
SQL， 这 条 SQL 包含 多 层 蔚 套 ， 其 执行 计划 有 几 十 行 甚至 上 百 行 之 多 。 遇 到 这 样 的 SQL 我 们 是 
和 否 就 束手无策 了 呢 ? 实际 上 ， 任 何 复杂 的 SQL 最 终 都 可 以 分 解 为 多 次 二 表 连 接 ， 因 此 完全 可 以 
从 这 里 找到 入 手 点 ， 从 而 解决 这 个 问题 。 比 如 ， 我 们 在 一 次 优化 中 发 现 某 条 SQL 对 系统 的 影 
很 大 ， 于 是 通过 AWRSQRPT 脚本 获取 了 完整 的 SQL 文本 ， 如 代码 清单 15-1 所 示 。 


代码 清单 15-1 


a 


select acct id,billing cycle,bill item name,item source пате, ёо _ 
char(sum(amount), ' FM999999990.90'] amount,stateName,stateDate 
rom( select a.acct id ,c.billing cycle,d.bill item name, e. name 


item source name,a.amount,f.name stateName,to char(a.state date, 
уууу- тт- аа hh24:mi:ss') stateDate from (select acct item type. 
id ,billing cycle id,acct id,item source id,state,state date,sum 
amount/100) amoun from select * from acct item where acct_ 
id 2165440341 and serv id =169002286374 and billing cycle id in 
10906) group by acct item type id,billing cycle id,acct id, 

item source id,state ,state date) a, (select billing cycle id ,to_ 
char(cycle end date -1,'yyyy-mm') billing cycle from billing сус 

e where state in(' 104, 10R', ' 10E' , ' 10D' and billing cycle id 


in(10906))c ,(select x.acct item type id ,y.bill item name, x. 
item source id from bill item acct item x ,bill item y , (select 
distinct invoice require id from serv acct where acct_id=165440 
341 and serv id -169002286374 ee , bill requemen f,bill form 
at bill item gg where x.bill item type id = y.bill item type id 
and ee.invoice require id = ff.require id and y.classifyz' 55A 
and ff.bill format id = gg.bill format id and gg.bill item type 
id = x.bill item type id)d ,acct item source e, (select domain 


name from v domain where table name =' АССТ_ ITEM' and field name- 
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'STATE' ) f where a.b 


illing cycle id - 


c.billing cycle id and a 


.acct item type ide d.acct item type id and a.item source id = d. 
item source id and a.item source id ze.item source id and e.ite 


m source type=' 52A' an 


d a.state=f.domain ) 


group by acct id , 


billing cycle,bill item пате, item source name,stateName,stateDate 


order by billing cycle 


想 看 懂 这 条 SQL 几乎 是 不 可 能 的 ,这 种 SQL 简直 会 让 我 们 崩 演 


贵 . 其 实 , 对 于 经 验 丰 富 的 DBA 


来 说 ， 问 题 并 没有 那么 严重 。 首 先 ， 我 们 需要 对 这 条 SQL 进行 格式 化 ， 很 多 工具 都 可 以 完成 此 
工作 ( 老 白 在 使 用 工具 之 前 一 直 是 手工 来 完成 格式 化 操作 的 , 整理 这 样 一 条 SQL, 可 能 需要 几 个 


小 时 )， 老 白 最 喜欢 使 用 的 是 


关系 ， 这 对 于 下 一 步 优化 工作 至 关 重 要 。 因 此 ， 如 果 没 有 合适 的 SQL 格式 化 . 


Oracle 的 SQL DEV 工具 。 


后 续 工 作 。 代 码 清单 15-2 是 格式 化 后 的 SQL 文本 。 


代码 清单 15-2 


SELECT acct_id, bi 
to_ CHAR( SUM( amount ) 
FROM 
(SELECT a.acct_id 
a. amount 
stateDate 
FROM 
(SE 
state, 
FRO 


LECT acct item 
state d 


SELECT * 
ROM acct item 


.Name stateName, 


, FM999999990.90') amount, 


c.billing cycle,d.bill item name 


type id, billing cycle id 
ate, SUM (amount/100) amount 


ling cycle,bill item name,item source name 
stateName, 


我 们 可 以 从 格式 化 后 的 SQL 中 看 出 层次 
工具 


AN. 


就 无 法 进行 


stateDate 


Item source name, 


acct id, 


TO CHAR(a.state date,'yyyy- тт- dd hh24: mi :ss') 


item source id, 


HERE acct_ id =165440341 
D serv id 2169002286374 
D billing cycle id IN (10906) 


一 二 二 三 一 一 


GROU 
) à 
(SE 
FRO 
WHE 
AND 
1C 5 
(SELECT x.acct item type id 
FROM bill item acct item x , bill item у 
LECT DISTINCT invoice require id 

ROM serv acct 

HERE acct_id=165440341 

D serv idz169002286374 

ee, 
bill requement ff, bill 
WHERE x.bill item type id 
AND ee.invoice require id 
AND y.classify 

AND ff.bill format id 
AND gg.bill item type _ 
)d , 
acct_ 


LECT billing cycle id 
billing cycle 

RE state [N( 10A  , 108, 10E', 10D') 
billing cycle id IN( 10906) 


to. CHAR(cycle end date -1, yyyy- mm 


y.bill item name, x.i tem source id 


SE 


> жоп 
° 


format_bill_item gg 
y.bill item type id 
ff.require id 


gg. bill format id 
x.bill item type id 


nou H H HI 
сл 
сл 
=> 


id 


item source e, 


PBYacct item type id, billing cycle id, acct id,item source id,state,state date 


billing cycle 
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(SELECT domain, name 
FROM v_domain 
WHERE table name ='ACCT_ITEM 
AND field name = 'STATE 
) f 
WHERE a. billing cycle id = c.billing cycle id 


AND a .acct item type id = d.acct item type id 

AND a.item source id = d .item source id 

AND a.item source id ze.item source id 

AND e.ite m source type ='52А 

AND a.state -f.domain 

) 
GROUP BY acct id , bi lling_cycle, bill item name, item source_name,stateName 
stateDate 


ORDER BY billing cycle 
ТЕ ЕЖ SQL 中 存在 大 量 的 inline 视图 ,这 使 得 整个 结构 十 分 复杂 。 我 们 需要 进行 相应 的 简化 ， 
找到 这 条 SQL 中 对 性 能 影响 最 大 的 部 分 ， 由 于 该 SQL 带 有 子 查 询 ， 因 此 可 以 先 将 子 查 询 单独 拿 


出 来 分 析 ， 如 代码 清单 15-3 所 示 。 
代码 清单 15-3 
(SELECT a.acct id , c.billing cycle,d.bill item name, ltem source name 
a.amount, .hame stateName, TO CHAR(a.state date, ' уууу- mm-dd hh24: mi:ss' 
stateDate 
FROM 
(SELECT acct item type id, billing cycle id, acct id, item source id 
state, state date, SUM (amount/ 100) amount 
FRO 
(SELECT * 
FROM acct item 
WHERE acct_ id =165440341 
AND serv_id =169002286374 
AND billing cycle id IN (10906) 
) 
GROUP BY acct item type id, billing cycle id, 


acct id,item source id,state ,state date 
) a, 
(SELECT billing cycle id , to CHAR(cycle end date -1,'yyyy-mm') billing cycle 
FROM billing cycle 


WHERE state IN( 10A, 10R' , ' 10E' , ' 10D') 
AND billing cycle id I N( 10906) ay 
)c 


(SELECT x.acct item type id , y.bill item name, x.i tem source id 
FROM bill item acct item x , bill item у 

SELECT DISTINCT invoice require id 

FROM serv acct 

WHERE acct_id=165440341 

AND serv id 169002286374 

ee, 
bill_requement ff, bill_format_bill_item gg 
WHERE x.bill item type id = y.bill item type id 
AND ee.invoice require id ff.require id 

AND y.classify "55А 
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AND ff.bill format id - gg.bill format id 

AND gg.bill item type id = x.bill item type id 
d, 

acct item source e, 

SELECT domain, name 

FROM v domain 

WHERE table name =' АССТ ITEM 

AND field name = 'STATE 


f 

WHERE a.billing cycle id 
AND a .acct item type id 
AND a.item source id d .item source id 
AND a.item source id e.item source id 
AND e.ite m source type -'52A 

AND a.state -f.domain 

) 


хул ДЕК T TAW, 3f TH ELS. FROM 语句 开始 向 下 分 析 ， 可 以 看 出 FROM 
语句 后 面 存 在 几 张 表 和 几 个 inline 视图 ， 其 别名 分 别 为 a、c、d、e、f， 如 代码 清单 15-4 所 示 。 


代码 清单 15-4 


视图 ] : 

(Select 
acct item type id ,billing cycle id,acct id,item source id,state,state date,sum 
(amount/ 100) 

amount from ( select * from acct item where acct id =165440341 and serv id 
-169002286374 

and billing cycle id in (10906)) group by 
acct item type id,billing cycle id,acct id, 

item source id,state ,state date 


c.billing cycle id 
d.acct item type id 


) a, 
视图 2 : 
(select billing cycle id ,to char(cycle end date -1,'yyyy-mm') billing cycle 
from billing cycle 
where state in('10A','10R','10E','10D') and billing cycle id in(10906) 
)c 
视图 3: 
select x.acct item type id ,y.bill item name, x.item source id from 
bill item acct item x ,bill item y 


(select distinct invoice require id from serv acct where acct_id=165440 341 and 
serv id -169002286374 

) ee , bill requement ff,bill form at bill item gg 

where x.bill item type id = y.bill item type id and ee.invoice require id = 
ff.require id and 

y.classifyz' 55А and ff.bill format id = gg.bill format id and 


gg.bill item type id = x.bill item type id 
)d 

Rl: 

acct item source e, 

视图 4 : 


(select domain, name from v domain where table name = АССТ ITEM' and 
field namez STATE ) f 
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经 过 上 面 的 分 析 , 可 以 看 出 这 个 查询 由 5 个 主要 部 分 关联 而 成 , 实际 上 , 我 们 需要 判断 的 是 ， 
针对 这 5 个 表 / 视 图 ， 应 该 采取 哪 种 连接 顺序 。 确 定 连接 顺序 需要 从 连接 关联 系 件 和 过 滤 条 件 开 
台 。 关 联系 件 如 代码 清单 15-5 所 示 。 


代码 清单 15-5 


a.billing cycle id = c.billing cycle id and 
a.acct item type ide d.acct item type id and 
a.item source id = d.item source id and 
a.item source id ze.item source id and 
e.item source typez' 52A' and 
a.state=f.domain 


从 这 里 可 以 看 出 ，a 表 是 核心 ， 其 他 表 均 通过 а 表 来 关联 。 这 个 查询 的 过 滤 条 件 很 少 ， 只 有 
е 表 上 存在 一 个 过 滤 和 条件。 通过 对 这 些 inline 视图 的 分 析 ， 我 们 并 没有 发 现 其 中 存在 重 秋 部 分 ， 
因此 不 需要 进行 深入 的 视图 合并 。 这 里 ,我 们 首先 考虑 ate 的 连接 组 合 ， 其 中 ,a 是 一 个 视图 ，e 
是 一 张 表 。 将 a 和 e 的 过 滤 条 件 及 连接 条 件 代 入 ， 就 得 到 了 一 个 ate 连接 的 等 价 SQL， 如 代码 清 
单 15-6 所 示 。 


代码 清单 15-6 
Select a.acct item type id , a.billing cycle id,acct id, a.item source id,a.state 
a.state date,sum(a.amount/100)amount from 
(select 
acct item type id ,billing cycle id,acct id,item source id,state,state date,sum 


(amount/ 100) 
Amount from ( select * from acct item where acct id 72165440341 and serv id 
7169002286374 
and billing cycle id in (10906) ) group by 
acct item type id,billing cycle id,acct id, 
item source id,state ,state date 
) a, Acct item source e 
Where 
a.item source id ze.item source id and 
e.item source typez' 52A 


接 下 来 ， 需 要 分 析 这 个 等 价 SQL 的 执行 计划 ， 我 们 已 经 将 分 析 集 中 在 一 个 二 表 连 接 的 优化 
上 上 了。 因此, 分析 相对 就 简单 了 许多 。 

从 上 面 的 SQL 可 以 看 出 ,a 的 数据 来 自 于 账目 表 ACCT_ITEM ( 这 是 电信 账 务 系统 中 一 张 很 
重要 的 表 , 存放 着 所 有 的 账目 ), 而 过 滤 是 通过 acct_id、serv_id ( 服务 ID ) 和 Pbilling_cycle id (Wl 
期 ) 这 三 个 等 于 条 件 进 行 的 ， 这 样 过 滤 出 来 的 数据 量 不 会 很 大 ， 一 般 只 有 几 条 到 几 百 条 。 

下 一 步 我 们 可 以 将 这 个 子 查询 产生 的 数据 存放 在 一 张 临时 表 中 , 然后 判断 ate 关联 的 结果 集 
以 及 其 他 几 个 表 连 接 时 产生 的 结果 集 的 数量 , 从 而 判断 下 一 步 和 哪 张 表 关联 会 比较 高 效 ( 如 果 分 
析 能 力 足 够 强 , 或 者 对 业务 比较 了 解 ， 也 可 以 直接 通过 业务 关系 进行 分 析 ， 这 个 示例 只 是 演示 在 
不 了 解 整个 业务 的 情况 下 该 如 何 分 析 SQL )， 如 代码 清单 15-7 所 示 。 


364 第 15% DBA 分 析 思 路 的 探讨 


代码 清单 15-7 
CREATE TABLE TMP_TBL1 AS 


Select a.acct item type id , a.billing cycle id,acct id, a.item source id,a.state 
a.state date,sum(a.amount/ 100) amount from 

(select 
acct item type id ,billing cycle id,acct id,item source id,state,state date,sum 


(amount/ 100) 

amount from ( select * from acct item where acct id 7165440341 and serv id 
-169002286374 

and billing cycle id in (10906)) group by 
acct item type id,billing cycle id,acct id, 

item source id,state ,state date 

) a, Acct item source e 
Where 
a.item source id ze.item source id and 
e.item source typez' 52А' 
EXEC DBMS STATS.GATHER TABLE STATS(OWNNAMEz2'...', TABNAME=>' TMP_TBL1) 


接 下 来 , 我 们 可 以 改写 SQL, 评估 其 他 表 和 TMP. TBLI 连接 时 的 执行 计划 , 如 代码 清单 15-8 
所 示 。 


代码 清单 15-8 
select c.* 
(select billing cycle id ,to char(cycle end date -1,'yyyy-mm ) billing cycle 
from billing cycle 


where state in('10A' , 108 ,' 10E',' 10D') and 
billing cycle id in(10906) 
)c , tmp tbllt 
where 
t.billing cycle id = c.billing cycle id 


如 果 这 个 查询 非常 复杂 ， 可 以 按照 前 面 的 方式 进行 分 拆 ， 直 到 能 够 很 清晰 地 进行 分 析 为 止 。 
这 样 ， 经 过 几 轮 的 分 拆 和 分 析 ， 就 可 以 将 一 个 复杂 的 SQL 执行 计划 分 析 得 很 透彻 了 。 

尽管 目前 的 SQL 分 析 工具 功能 很 强大 ， 已 经 可 以 分 析 大 多 数 SQL 的 性 能 了 ， 但 针对 特别 复 
杂 的 SQL， 工 具 的 能 力 毕 竟 还 是 有 限 的 ， 而 我 们 又 经 常会 遇 到 这 类 复杂 的 SQL， 因 此 ， 掌 握 好 
本 节 介 绍 的 方法 ， 才 是 处 理 复杂 SQL 的 关键 。 


15.10 理论 如 何 联系 实践 


老 白 在 本 书 中 多 次 提 到 理论 和 实践 的 结合 。 如 果 只 有 理论 而 无 实践 ,理论 只 是 空中 楼 阁 ， 中 
看 不 中 用 ; 但 如 果 只 有 实践 而 无 理论 ， 又 容易 流 于 表面 ， 经 常 是 治标 不 治本 。 理 论 联 系 实际 这 句 
话 大 多 数 DBA 都 清楚 ， 但 是 谈 到 如 何在 实际 工作 中 实现 ， 恐 怕 很 多 人 就 十 分 迷茫 了 。 

要 做 到 理论 联系 实际 , 首先 需要 比较 精准 地 掌握 理论 知识 , 但 这 并 不 是 要 求 大 家 都 去 深入 研 
究 某 个 操作 的 Oracle 内 部 实现 算法 , 其 实 只 要 理解 了 大 体 的 概念 , 基本 上 就 够 用 了 。 由 于 精力 有 
R, 一 个 人 不 可 能 把 成 千 上 万 人 开发 出 来 的 、 如 此 庞大 的 软件 系统 了 解 得 十 分 透彻 , 不 过 我 们 可 


15.10 ”理论 如 何 联 系 实践 365 


以 通过 Oracle 公布 的 一 些 官方 资料 以 及 网 络 上 类 似 DSI 这 样 的 资料 ， 粗 略 地 了 解 Oracle 各 个 功 

能 模块 、 组 件 的 基本 原理 和 算法 。 大 多 数 DBA 学 习 理 论 知 识 的 渠道 并 不 是 Oracle Concepts 这 本 

P, 而 是 在 网 络 上 拼命 搜罗 一 些 高 深 的 底层 核心 知识 , 这 样 掌握 的 知识 点 十 分 零散 ， 有 些 人 能 够 

将 部 分 知识 点 串 在 一 起 ， 而 大 多 数 人 了 人 解 的 只 是 一 个 个 孤立 的 点 ， 因 此 这 些 知 识 很 难 发 挥 作用 。 
前 段 时 间 ， 在 一 个 优化 项 目 中 ， 我 们 发 现 系统 的 共享 池 问 题 很 大 ， 相 关 分 析 报 告 如 下 : 


Cache Sizes 
A Begin End 
Buffer Cache: 4, 288M 4, 288M Std Block Size: 16K 
Shared Pool Size: 3,856M 3,856M Log Buffer: 14,292K 
Load Profile 
mmy Per Second Per Transaction 
Redo size: 32,512. T9 6,444.21 
Logical reads: 20,006.94 3,958.21 
Block changes: 206.09 40.77 
Physical reads: 19.91 15.81 
Physical writes: 4. 13 0.94 
User calls: 163.69 32.38 
Parses: 122.99 24.33 
Hard parses: 16.93 3.35 
Sorts: 21.48 5.44 
Logons: 0.10 0.02 
Executes: 131.80 26.07 
Transactions: 5.05 
% Blocks changed per Read: 1.03 Recursive Call %: 80.29 
Rollback per transaction %: 22.79 Rows per Sort: 459,53 
Instance Efficiency Percentages (Target 100%) 
Buffer Nowait %: 100.00 Redo NoWait 9: 100.00 
Buffer Hit 9 99.60 |n- memory Sort %: 100.00 
Library Hit 9 93.36 Soft Parse %: 86.23 
Execute to Parse %: 6.68 Latch Hit %: 99.91 
Parse CPU to Parse Elapsd %: 8.40 % Non- Parse CPU: 94.11 
Shared Pool Statistics Begin End 
Memory Usage %: 87.98 85.28 
% SQL with executions>l: 83.42 67.19 
% Memory for SQL w/exec>l: 91.20 80.17 
Top 5 Timed Events 
mmm % Tota 
Even Waits Ti me(s) Avg Wait(ms) Call Ti me Wait Class 
CPU ti me 2,54] 44.4 
latch: library cache 5,813 1,593 214 21.8 Concurrency 
latch: shared pool 4,932 1,303 264 22.1 Concurrency 
latch free 121 189 262 3.3 Other 
db file sequential read 31,799 139 4 2.4 User 1/0 
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大 家 可 能 马上 就 能 发 现 库 缓存 和 共享 池 门 锁 的 等 待 十 分 严重 , 系统 总 体 等 待 时 间 的 占 比 超过 
T 50%, 而 且 平 均 每 次 等 待 的 时 间 在 260 毫秒 左右 ， 而 从 后 面 的 等 待 事件 明细 来 看 , 平均 每 个 事 
务 等 待 这 些 门 锁 的 次 数 为 0.32, 也 就 是 说 ,在 一 个 事务 中 , 仪 仅 库 缓存 和 共享 门 锁 的 等 待 时 间 就 
超过 了 160 毫秒。 而 且 这 个 系统 已 经 多 次 出 现 由 “ 行 缓存 对 象 等 待 时 间 过 长 ”导致 的 挂 起 和 宕 机 
事件 。 我 们 分 析 了 这 个 应 用 系统 的 特点 , 由 于 该 系统 中 的 很 多 统计 查询 结果 都 是 先 存 储 在 临时 表 
中 ， 然 后 再 将 结果 显示 给 客户 ， 因 此 SQL 的 重用 率 较 低 ， 硬 解析 的 比重 很 高 ， 这 样 就 导致 了 共 
享 池 的 命中 率 不 高 , 仅 为 93%， 而 软 解析 的 比例 仅 为 86%。 按理 说 这 样 的 系统 ,如 果 使 用 了 共享 
内 存 自 动 管理 ， 那 么 共享 池 应 该 会 被 调整 得 很 大 。 但 从 报告 中 看 到 ， 共 享 池 仅 为 3 GBL, TÆ 
我 们 检查 了 SGA 的 配置 情况 ， 发 现 SGA_TARGET 参数 设置 为 28 GB ， 共 享 池 配置 了 3 GB，DB 
CACHE 配置 了 4GB， 保 留 池 配置 了 4GB， 回 收 池 配置 了 16 GB. 

从 这 些 配 置信 息 来 看 ， 客 户 对 这 个 系统 做 了 精心 的 设计 ， 而 且 设 置 这 些 参 数 的 DBA 肯定 对 
SGA 的 基本 原理 比较 了 解 ， 但 回收 池 的 配置 着 实 让 老 白 十 分 不 解 。 通 过 沟通 了 解 到 ， 设 置 如 此 
大 的 回收 池 的 目的 有 两 个 : 一 是 针对 几 张 很 大 的 表 ( 所 有 表 都 超过 1 GB, 最 大 的 表 有 10 GB Z ), 
其 数据 使 用 十 分 频繁 , 而 且 经 常 进行 分 区 扫描 , 为 了 确保 这 些 表 的 高 效 访问 , 才 将 其 放 入 回收 池 ， 
之 所 以 不 将 它们 放 入 保留 池 是 为 了 防止 其 冲击 池 中 的 数据 ; 二 是 为 了 防止 共享 池 过 度 扩张 。 

从 第 一 个 目的 来 看 ， 这 种 设计 十 分 巧妙 ， 不 仅 通 过 较 大 的 回收 池 实 现 了 类 似 保 留 池 的 功能 ， 
而 且 不 会 因为 某 个 较 大 的 扫描 操作 影响 保留 池 的 性 能 , 这 种 使 用 方法 虽然 不 合 常 规 , 但 也 是 没有 
任何 问题 的 。 不 过 第 二 点 老 白 就 觉得 不 可 思议 了 , 为 什么 要 以 回收 池 占 用 所 有 的 内 存 来 防止 共享 
池 扩 张 呢 ? 

经 过 了 解 ， 原 来 是 由 于 系统 中 大 量 临 时 表 的 使 用 ,共享 池 的 争 用 问题 一 直 十 分 严重 ， 对 系统 
性 能 和 稳定 性 都 造成 了 很 大 的 影响 。 他 们 在 网 络 上 查阅 了 大 量 的 资料 ， 其 中 有 不 少 文章 指出 , Ж 
享 池 过 大 会 增加 门 锁 争 用 ， 从 而 导致 更 为 严重 的 共享 池 性 能 问题 。 实 际 上 ,“ 过 大 ”这 个 概念 本 
身 就 十 分 模糊 , 于 是 他 们 进行 了 一 系列 的 实验 , 发 现 将 共享 池 配 置 为 3GB 时 性 能 最 佳 , 超过 4 GB 
性 能 反而 有 所 下 降 。 根 据 此 实验 结果 ， 他 们 最 终 设计 了 这 样 一 套 SGA 配置 方案 。 

经 过 综合 分 析 ， 老 白 的 优化 建议 如 表 15-2 所 示 。 


Жж 15-2 
5 щщ 调 整 值 

SGA_TARGET 50 GB 
DB_CACHE_SIZE 16 GB 
DB KEEP CACHE SIZE 8 GB 

DB RECYCLE CACHE SIZE 8GB 
SHARED POOL SIZE 8 GB 
SESSION CACHED CURSORS 100 


这 套 调 整 方案 提出 后 ,客户 感到 十 分 不 解 ， 对 于 将 共享 池 调 整 得 如 此 之 大 , 他 们 觉得 存在 很 
大 的 风险 ,也 和 老 白 发 生 了 多 次 和 争执， 甚至 暗示 如 果 系统 出 现 问 题 ， 我 们 必须 承担 全 责 。 当 时 优 
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化 小 组 的 成 员 对 此 也 捍 了 一 把 汗 , 不 过 老 白 却 十 分 淡定 , 并 表示 如 果 将 共享 池 设置 为 10 GB 甚至 
更 大 ， 效 果 会 更 好 。 

优化 实施 后 , 系统 性 能 得 到 了 明显 的 提升 , 但 在 每 天 业务 最 高 峰 时 还 是 会 出 现 一 些 共享 池 的 
门 锁 争 用 : 


Top 5 Timed Events 


wee % Total 

Event Waits Time(s) Avg Wait(ms) Call Ti me Wait Class 
CPU ti me 8,695 39.8 

latch: library cache 23,000 5,819 253 26.6 Concurrency 
latch: shared pool 18,650 4,190 251 21.9 Concurrency 
latch free 6,538 1,842 282 8.4 Other 
latch: row cache objects 2,601 109 212 3.2 Concurrency 


从 上 面 的 数据 来 看 , 问题 似乎 并 没有 解决 , 反而 更 严重 了 。 当 时 客户 对 优化 效果 提出 了 质疑 ， 
而 且 希 望 我 们 将 系统 恢复 到 原来 的 配置 。 但 老 白 却 认 为 优化 的 方向 并 没有 错 , 反而 应 该 进一步 加 
大 共享 池 , 将 其 设置 为 12 GB, 针对 此 观点 , 大 家 又 出 现 了 意见 的 不 一 致 , 因此 并 没有 马上 实施 。 
但 在 两 天 后 ， 共 享 池 争 用 逐渐 消失 了 。 


Cache Sizes 
аы Begin End 
Buffer Cache: 17,568M 17,568M Std Block Size: 16K 
Shared Pool Size: 13,056M 13,056M Log Buffer: 47, 016K 
Load Profile 
— Per Second Per Transaction 
Redo size: 705, 367. 85 21,262.35 
Logical reads: 63,030.79 1,899. 98 
Block changes: 3,570. 40 107. 62 
Physical reads: 739.17 22.28 
Physical writes: 52.17 1.357 
User calls: 4,294.22 129.44 
Parses: 1,460.07 44.01 
Hard parses: 88.11 2.66 
Sorts: 370.04 11.15 
Logons: 0.20 0.01 
Executes: 1,583.99 41.15 
Transactions: 33.11 
% Blocks changed per Read: 5.66 Recursive Call %: 71.00 
Rollback per transaction %: 3.30 Rows per Sort: 107.82 


Instance Efficiency Percentages (Target 100%) 


Buffer Nowait %: 99.98 Redo NoWait %: 100.00 
Buffer Hit %: 100.11 |n- memory Sort %: 100.00 
Library Hit %: 95.79 Soft Parse %: 93.97 
Execute to Parse %: 1.82 Latch Hit % 99.74 


Parse CPU to Parse Elapsd %: 67.31 % Non- Parse CPU: 90.58 
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Shared Pool Statistics Begin End 
Memory Usage %: 86.88 85.67 

% SQL with executions>l: 45,53 45.35 

% Memory for SQL м/ ехес>1: 49.16 46.81 


Top 5 Ti med Events 


SERIEN EQUES % Total Wait 
Event Waits Time(s) Avg Wait(ms) Call Ti me Class 
CPU ti me 11, 319 2.3 

eng: TX - row lock contention 11,886 4,986 419 1.0 Application 
row cache lock 908,103 462 1 .1 Concurrency 
log file parallel write 415,266 295 1 1 System 1/0 
SQL*Net more data to client 10,503,868 231 0 0 Network 


从 上 面 的 AWR 报告 来 看 ， 共 享 池 扩大 到 了 12 GB 多 ， 系 统 的 并 发 访问 量 也 大 幅 上 升 ， 而 共 
享 池 的 各 项 争 用 却 大 幅 减 少 了 , 共享 池 问 题 得 到 了 本 质 性 的 改善 .本 次 优化 的 初步 目标 已 经 达成 。 

在 这 样 一 种 充满 了 风险 的 情况 下 , 老 白 是 如 何 作 出 如 此 判断 , 并 最 终 获 得 成 功 的 呢 ? 在 实施 
初期 优化 效果 不 理想 的 情况 下 ,如 果 老 白 不 能 顶 住 压力 , 就 只 能 认为 这 个 系统 确实 不 适合 配置 过 
大 的 共享 池 ， 从 而 选择 回 退 操作 。 那 样 的 话 这 次 优化 就 彻底 失败 了 。 

正 是 因为 对 共享 池 概 念 的 理解 ， 老 白 才 选择 了 坚持 。 这 个 系统 CPU 资源 充足 ,平时 CPU 使 
用 率 不 足 20%， 内 存 容量 也 十 分 充足 ， 达 到 了 128 GB. 。 而 扩大 共享 池 可 能 带 来 的 副作用 只 是 管 
理 更 大 内 存 需 要 消耗 更 多 的 CPU 资源 ， 而 目前 系统 的 CPU 达到 了 32 核 ， 共 享 池 被 分 为 7 个 子 
池 ， 哪 怕 此 时 配置 14 GB 的 共享 池 ， 每 个 子 池 也 不 过 只 有 2 GB 的 容量 。 在 Oracle 8i 的 系统 中 ， 
配置 2GB 的 共享 池 都 不 会 导致 特别 严重 的 门 锁 争 用 问题 , 更 何况 是 大 幅 增加 了 LRU Bucket 数量 
的 9i 及 后 续 版 本 。 老 白 坚 信 加 大 共享 池 的 正面 作用 远大 于 负面 影响 ， 因 此 才能 够 从 容 应 对 。 

而 客户 对 共享 池 的 认识 受到 了 网 络 上 一 些 不 够 严谨 的 文章 的 误导 ， 存 在 一 定 的 误区 。 男 外 ， 
他 们 进行 的 实验 也 不 够 完整 , 仅 测试 了 4 GB 共享 池 下 的 性 能 情况 , 就 认定 共享 池 不 能 超过 4GB ， 
如 果 当 时 他 们 能 够 测试 到 10GB, 甚至 14 GB 共享 池 下 的 性 能 情况 ,那么 可 能 得 到 的 就 是 另外 一 
个 结论 了 。 

从 上 述 案 例 中 , 我 们 可 以 得 到 几 点 启示 。 首 先 , 我 们 掌握 的 知识 必须 是 十 分 准确 的 ， 而 错误 
的 、 不 严谨 的 知识 只 能 带 来 副作用 ; ЖК, LEIP ANT RIA, ТЕШ BP, 我们 不 需 
要 真正 了 解 共享 池 以 及 门 锁 的 具体 算法 ， 只 要 掌握 共享 池 的 基本 原理 就 足以 作出 合理 的 判断 了 ; 
最 后 ， 有 时 实验 并 不 能 完全 说 明 问题 ， 因 为 实验 的 场景 、 范 围 可 能 存在 缺陷 ,根据 这 样 的 实验 得 
出 的 结论 其 准确 性 会 大 打折 扣 。 

在 本 节 中 , 老 白 并 没有 讲述 如 何 将 Oracle 的 理论 和 实践 完美 结合 , 因为 这 是 不 可 能 完成 的 工 
TE, Oracle 的 知识 点 不 计 其 数 ， 实 践 技巧 更 是 五 花 八 门 。 老 白 只 能 通过 具体 案例 让 大 家 理解 如 何 
运用 自己 的 知识 ， 实 现 相对 的 结合 。 
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典型 案例 是 学 习 维 护 技巧 十 分 重要 的 手段 ， 为 了 让 大 家 能 够 对 本 书 介绍 的 理论 和 方法 有 更 
深 的 理解 ， 老 和 白 精 心 挑 选 了 10 多 个 案例 ， 这 些 和 案例 都 有 各 自 不 同 的 精彩 之 处 ,按照 本 书 的 内 容 ， 
可 分 为 КАС 故障 分 析 、 性 能 优化 、 故 障 处 理 等 几 个 童 市 。 

大 家 在 学 习 这 些 案例 时 ， 如 果 对 照 前 面 章节 所 介绍 的 基础 知识 和 方法 ， 就 能 对 本 书 的 思想 
有 更 深入 的 理解 。 学 习 案 例 需 要 举一反三 , 这样 才能 对 今后 的 工作 有 所 帮助 。 如 果 只 是 照 本 宣 科 ， 
那么 这 些 案例 也 就 没有 什么 价值 了 。 


第 16 = 
RAC 故障 分 析 


RAC 故障 主要 集中 在 集群 故障 、RAC 实例 故障 、RAC 性 能 问题 等 儿 个 方面 ,很 多 DBA ik 
Z RAC 方 面 的 分 析 经 验 ， 这 样 就 很 难 找 到 问题 的 根本 原因 。 

本 章 的 目的 是 让 读者 了 解 RAC 分 析 的 方法 和 思路 ,通过 学 习 这 些 简单 的 案例 ， 我 们 就 可 以 
掌握 RAC 故障 分 析 的 一 般 方法 。 


16.1 LOG ARCHIVE MAX PROCESS 导致 的 RAC А2 


今天 一 上 班 就 接 到 客户 的 电话 ，RAC 中 的 一 个 数据 库 实例 登 不 上 去 了 。 于 是 ,我 马上 通过 
VPN 连接 系统 , 首先 检查 了 所 有 节点 的 ALERTLOG Н, Æ ВАСІ 节点 的 ALERTLOG 日 志 中 ， 
可 以 看 到 : 


Tue Dec 14 07:10:39 2010 

ARC7: Attempting destination LOG ARCHI VE DEST 2 network reconnect (3113) 
ARC7: Destination LOG ARCHIVE DEST 2 network reconnect abandoned 
PING[ARC7]: Error 3113 when pinging standby exp5 physical std 

Tue Dec 14 07:40:45 2010 
PC Send timeout detected. Sender: ospid 1672116 
Receiver: inst 2 binc 344730067 ospid 198544 
Tue Dec 14 07:41:11 2010 
PC Send timeout to 1.3 inc 80 for msg type 65516 from opid 9 
Tue Dec 14 07:43:52 2010 
Evicting Instance 2 from cluster 
Tue Dec 14 07:44:35 2010 
Waiting for Instances to leave:2 
Tue Dec 14 07:44:55 2010 
Waiting for Instances to leave:2 
Tue Dec 14 07:45:15 2010 
Waiting for Instances to leave:2 

Tue Dec 14 07:45:35 2010 

Waiting for Instances to leave:2 

Tue Dec 14 07:45:47 2010 

PC Send ti meout detected. Sender: ospid 1253834 
Receiver: inst 2 binc 344730053 ospid 148480 
Tue Dec 14 07:45:55 2010 

Waiting for Instances to leave:2 

Tue Dec 14 07:46:10 2010 
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PC Send timeout to 1.1 inc 80 for msg type 73 from opid 7 
Tue Dec 14 07:46:15 2010 
Waiting for Instances to leave:2 
Tue Dec 14 07:46:35 2010 
Waiting for Instances to leave:2 
Tue Dec 14 07:46:55 2010 
Waiting for Instances to leave:2 
Tue Dec 14 07:47:15 2010 
Tue Dec 14 07:53:31 2010 
Trace dumping is performing id=[cdmp_20101214075331] 
Tue Dec 14 07:53:34 2010 
Reconfiguration started (old inc 80, new inc 84) 
List of nodes 

0 2 

Global Resource Directory frozen 

* dead Instance detected - domain 0 invalid = TRUE 
Communication channels reestablished 

* domain 0 not valid according to Instance 2 
Tue Dec 14 07:53:34 2010 
aster broadcasted resource hash value bitmaps 
on-local Process blocks cleaned out 
Tue Dec 14 07:53:34 2010 
LMS 1: 59 GCS shadows cancelled, 6 closed 
ue Dec 14 07:53:34 2010 
LMS 4: 105 GCS shadows cancelled, 9 closed 
Tue Dec 14 07:53:34 2010 
LMS 2: 100 GCS shadows cancelled, 7 closed 
ue Dec 14 07:53:34 2010 
LMS 0: 114 GCS shadows cancelled, 11 closed 
Tue Dec 14 07:53:34 2010 
LMS 5: 90 GCS shadows cancelled, 13 closed 
ue Dec 14 07:53:34 2010 
LMS 3: 113 GCS shadows cancelled, 6 closed 
Set master node info 
Submitted all remote-enqueue requests 
Dwn-cvts replayed, VALBLKs dubious 
All grantable enqueues granted 

Post SMON to start 151 pass IR 


不 难看 出 , 在 时 间 点 7:10:39 出 现 了 DATAGUARD 归档 故障 的 报错 , 这 个 错误 很 可 能 和 实例 
宕 掉 有 关 。 于 是 我 让 客户 确认 DATAGUARD 是 否 存在 问题 。 经 过 检查 发 现 ， 这 个 库 每 天 早上 都 
会 停止 DATAGUARD， 并 将 DATAGUARD 的 数据 文件 通过 LVM 同步 到 远 端 的 一 个 存储 中 ， 供 
其 他 业务 系统 使 用 。 出 现 报错 的 时 间 点 和 上 述 操作 的 时 间 是 吻合 的 。 

从 上 述 日 志 来 看 ，RAC1 节点 和 RAC2 节点 通信 时 出 现 了 IPC 超时 ， 系 统 进行 了 仲裁 ， 将 
RAC2 节点 驱逐 了 ， 接 下 来 我 们 检查 了 RAC2 节点 的 ALERTLOG 日 志 : 


Tue Dec 14 07:11:42 2010 

ARC5: Attempting destination LOG ARCHI VE DEST 2 network reconnect (3113) 
ARC5: Destination LOG ARCHIVE DEST 2 network reconnect abandoned 
PING[ARC5]: Error 3113 when pinging standby exp5 physical std 

Tue Dec 14 07:17:26 2010 

Process q000 died, see its trace file 
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Tue Dec 14 07:17:26 2010 

ksvcreate: Process(q000) creation failed 

Tue Dec 14 07:24:11 2010 

ksvcreate: Process(q000) creation failed 

Tue Dec 14 07:44:16 2010 

ksvcreate: Process(q002) creation failed 

Tue Dec 14 07:46:46 2010 

MNL absent for 1201 secs; Foregrounds taking over 
Tue Dec 14 07:46:46 2010 
MNL absent for 1201 secs; Foregrounds taking over 
Tue Dec 14 07:50:17 2010 
PC Send timeout detected. Receiver ospid 198544 
Tue Dec 14 07:50:20 2010 
Errors in file /dba/app/loracle/admin/szjf/bdump/szjf2 1 т2 198544.trc 
Tue Dec 14 07:52:57 2010 
PC Send ti meout detected. Receiver ospid 148480 

Receiver is waiting for a latch dumping latch state for receiver -17260 
Tue Dec 14 07:52:57 2010 
Errors in file /dba/app/loracle/admin/szjf/bdump/szjf2 Ims0 148480.trc 
Tue Dec 14 07:53:29 2010 
ARC9: terminating Instance due to error 481 
Tue Dec 14 07:53:29 2010 
Errors in file /dba/app/loracle/admin/szjf/bdump/szjf2 lmon 111882.trc 
ORA- 29740: evicted by member 2, group incarnation 82 


在 上 述 日 志 中 ， 我 发 现 RAC? 节点 在 时 间 点 7:11:42 也 出 现 了 类 似 的 归档 故障 ， 随 后 在 时 间 
点 7:50:17 出 现 了 LMS2 进程 的 了 PC 超时 , 在 时 间 点 7:52:57 出 现 了 LMSO 进程 的 IPC 超时 , 在 时 
间 点 7:53:29 由 于 节点 被 驱逐 ， 所 以 ARCO 进程 终止 了 实例 。 

在 后 面 的 ALERTLOG 日 志 中 ,我 发 现 此 时 数据 库 已 经 在 进行 重启 : 


Successful mount of redo thread 2, with mount id 1617700910 
Tue Dec 14 07:55:29 2010 
Database mounted in Shared Mode (CLUSTER DATABASE-TRUE) 
Completed: ALTER DATABASE MOUNT 

Tue Dec 14 07:55:30 2010 

ALTER DATABASE OPEN 

Picked broadcast on commit scheme to generate SCNs 


经 过 沟通 ， 得 知 数据 库 已 经 重启 了 一 段 时 间 ， 不 过 一 直 停留 在 SCN 广播 通信 上 ， 已 经 有 30 
多 分 钟 没 有 任何 响应 了 。 

在 10g 版 本 中 ，SCN 广播 是 实时 模式 的 ， 一 般 延 时 很 小 ， 因 此 这 个 环节 不 会 持续 较 长 时 间 ， 
但 目前 系统 已 经 等 待 了 30 多 分 钟 ， 仍 未 完成 数据 库 的 打开 ， 这 是 十 分 不 正常 的 。 由 于 9 点 是 公 
司 的 上 班 时 间 , 为 了 不 影响 整个 公司 的 运作 , 我 决定 再 次 重启 这 个 实例 , 不 过 重启 过 程 还 是 没有 
成 功 ， 仍 然 停留 在 上 回 的 那个 地 方 。 


Database mounted in Shared Mode (CLUSTER_DATABASE=TRUE) 
Completed: ALTER DATABASE MOUNT 

Tue Dec 14 08:32:09 2010 

ALTER DATABASE OPEN 

Picked broadcast on Commit scheme to generate SCNs 
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到 底 是 什么 原因 导致 实例 无 法 打开 呢 ? 我 首先 检查 了 REDO LOG 日 志 的 状态 ， 通 过 查询 
V$LOG， 发 现 了 一 个 异常 ，2 号 实例 中 存在 一 个 处 于 活动 状态 的 REDO LOG 日 志 ， 这 个 日 志 是 
未 归档 状态 的 。 


GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS 
9 2 8690 52428800 2 YES CURRENT 
10 2 8686 52428800 2 YES | NACTI VE 
11 2 8684 52428800 2 YES INACTIVE 
12 2 8685 52428800 2 YES INACTIVE 
13 2 8686 52428800 2 YES INACTIVE 
14 2 8687 52428800 2 YES INACTIVE 
15 2 8688 52428800 2 YES INACTIVE 
16 2 8689 52428800 2 NO ACTIVE 


TÆ, RE Metalink 上 搜索 了 “Picked broadcast on commit scheme to generate SCNs", 182 
结果 如 图 16-1 所 示 。 


€ Boraclecom ht: oracle.com mls 8 3 8 © e | 图- гт P|) ©- fiS- 
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Search: Picked broadcast on commit scheme to generate SCNs 
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Source. " 


names then It is possble for a session to pick up an unbound type checked cursor for a different 


All Sources [Artide ID 560295.1] 
Knowledge Base D 04 Feb 2012 10.2.0.x Oracle Database and Networking Patches for Microsoft Platforms 
Knowledge Base Archive = logmnr_contents against logs which were generated without supplemental logging enabled may 
All Bugs [Artide ID 342443.1] 
Communities 20 Oct 2010 MAX_COMMIT_PROPAGATION_DELAY In A Real Application Clusters Environment 
Documentation m after a commit. The default ... common are the "Lamport" scheme and "Broadcast on Commit" scheme. The scheme chosen is a function of the 
Sun System Handbook [Artide ID 259454.1] 
Patches Æ 205ер 2010 ORA-00600: [2702] during startup of one node 
S... Product Category ы instance was frst to open Picked broadcast on commit scheme to generate SCNs Tue Apr 29 12:27:33 2008 Errors 


All Products > Orade Database Products > Oracle [Artide ID 565940.1] 


€— > ads рге > Oratie Server 5 nere 2012 Instance Termination by dbwr with ORA-00600: [1433], [60] 
nterprise Edition 


agent *//* (1:65326:57315) S ROLE comes еее оныар Jan 06 15:39:46 2012 SUCCESS 
— gs: dbwr; exadata; instance terminated [Artide ID 1404964.1] 
D Product Release 
У lamAntent. 


Configure (1) se the Refine Search area to filter the se 
Al 16-1 


其 中 ，ORA-00600: [2702] during startup of one node [ID 565940.1] 虽 然 和 我 们 目前 碰 到 的 情形 
不 完全 一 致 , 但 是 具有 一 定 的 相似 性 。 通 过 分 析 这 篇 文档 , 我 决定 立即 关闭 所 有 的 实例 ， 进 行 一 
次 数据 库 恢复 操作 ， 然 后 再 启动 实例 。 

通过 和 业务 部 门 以 及 上 级 主管 部 门 的 协商 ， 我 们 决定 在 8 点 40 分 关闭 其 他 两 个 正常 工作 的 
实例 ， 在 进行 数据 库 恢 复 操作 后 重启 数据 库 。 


Tue Dec 14 09:02:38 2010 
ALTER DATABASE RECOVER database 
Media Recovery Start 
parallel recovery started with 16 processes 
Tue Dec 14 09:02:54 2010 
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Recovery of Online Redo Log: Thread Group 31 Seq 104077 Reading mem 0 
em# 0: /dev/rv_redo2_13 

Tue Dec 14 09:02:54 2010 

Recovery of Online Redo Log: Thread Group 7 Seq 133118 Reading mem 0 
em# 0: /dev/rv_redol_03 

Tue Dec 14 09:02:54 2010 

Recovery of Online Redo Log: Thread Group 43 Seq 69756 Reading mem 0 
em# 0: /dev/rv_redo3_11 

Tue Dec 14 09:03:01 2010 

Recovery of Online Redo Log: Thread Group 44 Seq 69757 Reading mem 0 
em# 0: [dev/rv redo3 12 

Tue Dec 14 09:03:03 2010 

Recovery of Online Redo Log: Thread Group 8 Seq 133119 Reading mem 0 
em# 0: /dev/rv redol 04 

Tue Dec 14 09:03:09 2010 

Recovery of Online Redo Log: Thread Group 9 Seq 133120 Reading mem 0 
em# 0: [dev/rv redol 05 

Tue Dec 14 09:03:10 2010 

Recovery of Online Redo Log: Thread Group 32 Seq 104078 Reading mem 0 
em# 0: /dev/rv_redo2_14 

Tue Dec 14 09:03:12 2010 

Recovery of Online Redo Log: Thread Group 45 Seq 69758 Reading mem 0 
em# 0: |dev/rv redo3 13 

Tue Dec 14 09:03:16 2010 

Recovery of Online Redo Log: Thread Group 10 Seq 133121 Reading mem 0 
em# 0: /dev/rv redol 06 

Tue Dec 14 09:03:25 2010 

Recovery of Online Redo Log: Thread Group 11 Seq 133122 Reading mem 0 
em# 0: [dev/rv redol 07 

Tue Dec 14 09:03:30 2010 

Recovery of Online Redo Log: Thread Group 33 Seq 104079 Reading mem 0 
em# 0: [dev/rv redo2 15 

Tue Dec 14 09:03:31 2010 

Recovery of Online Redo Log: Thread Group 46 Seq 69759 Reading mem 0 
em# 0: /dev/rv_redo3_14 

Tue Dec 14 09:03:35 2010 

Recovery of Online Redo Log: Thread Group 12 Seq 133123 Reading mem 

Tue Dec 14 09:03:41 2010 

Recovery of Online Redo Log: Thread Group 13 Seq 133124 Reading mem 0 
em# 0: /dev/rv_redol 09 

Tue Dec 14 09:03:45 2010 

Recovery of Online Redo Log: Thread Group 14 Seq 133125 Reading mem 0 
em# 0: /dev/rv redol 10 

Tue Dec 14 09:03:46 2010 

Recovery of Online Redo Log: Thread Group 47 Seq 69760 Reading mem 0 
em# 0: /dev/rv_redo3_15 

Tue Dec 14 09:03:50 2010 

Recovery of Online Redo Log: Thread Group 15 Seq 133126 Reading mem 0 
em# 0: [dev/rv redol 11 

Tue Dec 14 09:03:52 2010 

Recovery of Online Redo Log: Thread Group 16 Seq 133127 Reading mem 0 
em# 0: [dev/rv redol 12 
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Tue Dec 14 09:03:54 2010 
Recovery of Online Redo Log: Thread 1 Group 17 Seq 133128 Reading mem 0 
Mem# 0: /dev/rv redol 13 
Tue Dec 14 09:03:54 2010 
Recovery of Online Redo Log: Thread 3 Group 48 Seq 69761 Reading mem 0 
Mem# 0: /dev/rv redo3 16 
Tue Dec 14 09:03:57 2010 
Recovery of Online Redo Log: Thread 1 Group 18 Seq 133129 Reading mem 0 
Mem# 0: /[dev/rv redol 14 
Tue Dec 14 09:03:59 2010 
Recovery of Online Redo Log: Thread 1 Group 19 Seq 133130 Reading mem 0 
Mem# 0: /dev/rv redol 15 
Tue Dec 14 09:04:03 2010 
Recovery of Online Redo Log: Thread 1 Group 20 Seq 133131 Reading mem 0 
Mem# 0: /|dev/rv redol 16 
Tue Dec 14 09:04:03 2010 
Recovery of Online Redo Log: Thread 3 Group 5 Seq 69762 Reading mem 0 
Mem# 0: /dev/rv_redo3_01 

Tue Dec 14 09:04:04 2010 
Media Recovery Complete 

Completed: ALTER DATABASE RECOVER database 


RECOVER DATABASE 操作 正常 结束 ， 然 后 我 们 也 正常 地 打开 了 数据 库 。 完 成 КАСІ 节点 
的 恢复 操作 后 ， 重 启 RAC2 节点 ， 也 是 先 以 STARTUP MOUNT 方式 启动 ， 确 认 加 载 正常 后 再 打 
开 数 据 库 。 接 下 来 ， 使 用 同样 的 方法 处 理 RAC3 节点 。 终 于 , 在 9 点 15 分 所 有 的 节点 都 正常 打 
开 了 ， 系 统 全 部 恢复 正常 。 由 于 ВАСІ 节点 在 9 点 5 分 左右 正常 启动 ， 主 系统 在 9 点 10 分 左右 
完全 恢复 ， 因 此 本 次 故障 虽然 没 能 在 9 点 之 前 完成 恢复 , 但 是 已 经 将 影响 降 到 了 最 低 ， 可 以 算是 
一 次 较为 成 功 的 故障 恢复 。 

完成 系统 恢复 后 ， 我 们 马上 开始 诊断 问题 出 现 的 原因 。 通 过 NMON 数据 我 们 发 现 故障 发 生 
前 RAC2 节点 的 CPU 使 用 率 突然 从 30% 左 右 暴 增 ， 如 图 16-2 所 示 。 
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从 图 中 可 以 看 出 ,CPU 使 用 率 从 不 到 10% 增 长 到 接近 90% ,然后 出 现 了 较为 严重 的 IOWAIT, 
再 往 后 数据 库 就 宕 掉 了 。 下 面 来 看 一 看 这 个 时 间 段 内 的 磁盘 情况 ， 如 表 16-1 所 示 。 


表 16-1 
时 间 HDISK1 HDISKO CDO HDISK10 
7:00:27 7.4 7.5 0 13.8 
7:05:55 101 100 0 0.5 
7:10:56 99.3 99.1 0 0.3 
7:16:14 99.4 99.7 0 0.2 
7:21:24 101 101 0 0.3 
7:27:07 99.4 99.8 0 0.3 
7:32:11 97.6 97.6 0 0.3 
7:37:23 99.5 99.6 0 0.3 
7:42:32 99.7 99.8 0 0.2 
7:48:55 101 101 0 0.1 
7:55:15 75.1 71.1 0 0.2 
8:00:15 2.9 5.2 0 0.4 


可 以 看 出 ,HDISK1 和 HDISK0 7:05:55 开始 突然 变 得 繁忙 起 来 ,直到 时 间 点 7:55:15 
才 降 下 来 。 如 果 系 统 盘 繁忙 , 我们 的 第 一 怀疑 对 象 就 是 换 页 。 于 是 我 们 查看 了 换 页 ( page ) 情况 ， 
如 图 16-3 所 示 。 
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从 这 张 图 来 看 , 在 系统 盘 繁 忙 的 这 段 时 间 内 , 确实 出 现 了 严重 的 换 页 。 这 个 现象 可 以 解释 为 
什么 КАСІ 市 点 会 对 RAC2 节点 发 起 驱逐 操作 ， 由 于 换 页 频繁 ，CPU 被 耗 尽 ， 因 此 导致 RAC2 
节点 被 驱逐 。 下 一 步 需要 了 解 为 什么 会 出 现 CPU 突 增 的 现象 。 对 照 NMON 报告 中 CPU 突 增 的 
时 间 点 ， 在 查看 ALERT LOG 日 志 后 我 们 发 现 ,由 于 DATAGUARD 停止 接收 日 志 ， 所 以 远程 归 
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档 失 败 ， 此 时 大 量 归档 进程 被 启动 ， 不 断 地 进行 重 试 ( retry ) 操作 ， 而 当时 正好 物理 内 存 空闲 空 
间 较 小 ,又 出 现 了 大 量 的 换 页 ， 因 此 就 导致 了 故障 。 为 防止 归档 进程 再 次 消耗 过 多 资源 ,我 建议 
客户 将 归档 进程 的 最 大 数 设置 为 3: 

ALTER SYSTEM SET log archive max_processes=3 SCOPE=BOTH SIDz'*'; 

至 此 ， 这 个 问题 似乎 已 经 解决 了 , 我 也 根据 处 理 的 过 程 向 客户 提交 了 故障 处 理 报告 , 不 过 总 
是 觉得 好 像 还 有 些 问 题 没有 搞 清 楚 。 于 是 ,我 在 周末 又 查看 了 这 个 案例 的 文档 ,突然 发 现 了 一 个 
新 的 情况 ， 如 图 16-4 所 示 。 
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从 这 张 图 中 可 以 看 出 ， 在 故障 发 生前 ， 物 理 内 存 的 使 用 率 是 7096, Н Р MAXPERM% 参 数 
设置 为 20%， 因 此 这 部 分 物理 内 存 就 被 NOCOMP 内 存 使 用 了 。 在 大 量 归 档 进程 启动 时 ， 物 理 内 
存 突然 被 耗 尽 了 ， 此 时 NOCOMP 内 存 开始 释放 ， 这 个 过 程 持续 了 20 多 分 钟 。 看 来 还 需要 对 这 
个 系统 做 进一步 的 调整 ， 为 了 确保 今后 系统 的 稳定 运行 ， 将 MAXPERM% 参 数 的 值 减少 到 10% 
是 很 有 必要 的 。 
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晚上 7 点 左右 ,突然 接 到 客户 的 求助 电话 ,数据库 出 现 了 一 些 问题 ,有 一 个 节点 重启 了 ， 而 
重启 后 系统 一 直 比 较 慢 , 需要 我 帮忙 分 析 问 题 原因 并 尽快 恢复 系统 。 于 是 , 我 马上 登录 系统 进行 
Лт, 按照 惯 例 ， 首 先 检查 了 ALERTLOG His. 日 志 中 并 无 异常 ， 只 是 日 志 切 换 的 频率 似乎 比 
平时 低 了 ， 从 以 往 的 经 验 来 看 ， 这 种 现象 说 明 系 统 的 性 能 存在 问题 ， 导 臻 单位 时 间 的 REDO = 
出 现 了 较 大 的 下 降 。 

在 这 种 情况 下 ,马上 进行 HANGANALYZE 分 析 是 十 分 必要 的 。 通过 HANGANALYZE 报告 
可 以 看 出 ,节点 1 中 大 量 的 会 话 被 挂 起 了 ,并 且 存 在 大 量 GC BUFFER BUSY WAIT 等 待 的 会 话 ， 
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杀 掉 其 中 几 个 阻塞 严重 的 会 话 后 ， 节 点 1 恢复 正常 。 

处 理 完 节点 1 后， 节点 2 的 情况 并 未 得 到 改善 ,运行 仍然 缓慢 。 于 是 ， 我 使 用 同样 的 方法 
对 节点 2 进行 了 HANGANALYZE 分 析 ， 发现 节点 2 也 存在 大 量 挂 起 的 会 话 。 这 时 已 经 是 晚上 
的 7 点 30 分 了 ， 由 于 从 晚上 8 点 开始 ， 节 点 2 上 有 一 个 十 分 重要 的 批 处 理 要 运行 ， 在 和 客户 
沟通 后 ,我 决定 先 恢复 应 用 再 分 析 问 题 ， 并 建议 马上 重启 这 个 实例 。 实 例 2 重启 后 ， 系 统 恢复 
正常 。 

此 时 就 需要 进一步 分 析 问 题 的 原因 了 。 我 再 次 仔细 检查 了 ALERTLOG 日 志 , 发 现 这 个 RAC 
中 的 节点 3 在 时 间 点 18:52 附近 出 现 了 故障 ， 并 且 进 行 了 自动 重启 ， 之 后 就 出 现 了 系统 挂 起 的 现 
象 。 造成 此 现象 主要 原因 是 节点 1 在 帮助 节点 3 进行 实例 恢复 时 出 现 了 大 量 的 全 局 热 块 冲突 ， 从 
而 导致 了 问题 。 


Fri Aug 20 18:52:31 2010 
IPC Send timeout detected.Sender: ospid 217768 
Receiver: inst 3 binc -632201635 ospid 422018 

Fri Aug 20 18:52:40 2010 
IPC Send timeout to 2.8 inc 6 for msg type 73 from opid 8 
Fri Aug 20 18:52:40 2010 
Communications reconfiguration: Instance number 3 
Fri Aug 20 18:52:50 2010 
Trace dumping is performing id=[cdmp_20100820185240 
Fri Aug 20 18:52:57 2010 
PC Send timeout detected. Sender: ospid 177036 
Receiver: inst 3 binc -632201634 ospid 357254 

Fri Aug 20 18:53:24 2010 
PC Send timeout to 2.7 inc 6 for msg type 65516 from opid 7 
Fri Aug 20 18:55:30 2010 
PC Send timeout detected. Sender: ospid 405882 
Receiver: inst 3 binc -632201643 ospid 164598 

Fri Aug 20 18:55:30 2010 
PC Send ti meout detected. Sender: ospid 836012 
Receiver: inst 3 binc -632201634 ospid 357254 

Fri Aug 20 18:55:30 2010 
PC Send timeout detected. Sender: ospid 926704 
Receiver: inst 3 binc -632201642 ospid 438612 

Fri Aug 20 18:55:30 2010 
PC Send timeout detected. Sender: ospid 856508 


从 节点 工 的 日 志 中 可 以 看 出 ， 在 时 间 点 18:52:31， 出 现 了 第 一 个 IPC 超时 报警 ， 


PC Send timeout detected.Sender: ospid 217768 
Receiver: inst 3 binc -632201635 ospid 422018 


这 是 因为 节点 1 与 节点 3 的 422018 进程 通信 出 现 了 故障 。 另 外 ， 节 点 2 与 节点 3 的 422018 
进程 也 出 现 了 通信 和 故障。 于是， 下 一 步 的 工作 重点 就 是 排查 422018 进程 的 trace 文件 ， 该 文件 的 
详细 信 ， 息 如 下 : 


*** 2010-08-20 18:47:22.933 
SKGXP TRACE FLUSH: output truncated 18 traces lost 
SKGXP TRACE FLUSH: start 
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422018 <- 475916)SKGXPDOCON:can't accept new connections under timed wait contex 
422018 <- 475916)SKGXPDOCON:can't accept new connections under timed wait contex 
422018 «- 475916)SKGXPDOCON: can't accept new connections under timed wait contex 
422018 <- 495936) 5КСХР”ОСОМ: can't accept new connections under timed wait contex 
422018 «- 930222)SKGXPDOCON: can't accept new connections under timed wait contex 
422018 <- 635400)SKGXPDOCON: can't accept new connections under timed wait contex 
422018 «- 357116)SKGXPDOCON: can't accept new connections under timed wait contex 
422018 «- 578732)SKGXPDOCON: can't accept new connections under timed wait contex 
422018 <- 636266)SKGXPDOCON: can't accept new connections under timed wait contex 
422018 «- 491916)SKGXPDOCON: can't accept new connections under timed wait contex 
422018 «- 688192)SKGXPDOCON:can't accept new connections under timed wait contex 


422018 «- 525226)SKGXPDOCON: can't accept new connections under timed wait contex 
SKGXP TRACE FLUSH: end 
*** 2010-08-20 18:53:23.983 
KJM HI STORY: RCVR STALL OP(14) context 32 elapsed 342061334 us 
KJ M HI ST LMS7: 
14:32:342061334 1:1 14:32:84561 1:0 14:32:52 1:0 14:32:49819 1:11 14:32:78688 1:0 
14:36:52 1:0 14:32:78 1:0 14:32:63 1:1 14:32:48 1:0 14:32:79 1:0 
14:32:71 1:0 14:32:73 1:0 14:32:19 1:0 14:36:29 1:0 14:32:22 1:0 
14:32:40 1:0 14:32:136066 1:0 14:32:43 1:0 14:32:126240 1:0 14:32:78 1:0 
12:20:62 7:8 6:28 10:0 17:4 16:15 15:1 14:32:88296 1:0 14:32:87 
1:0 14:32:73 1:0 14:32:24 1:1 14:36:35 1:0 14:32:33 1:1 14:32:41 
1:0 14:32:62 1:0 14:32:13172 
S0: 7000007023e8670, type: 4, owner: 7000007042bbf60, flag: INIT/-/-/0x00 
(session) sid: 1313 trans: 0, creator: 7000007042bbf 60, flag: (51) USR/- BSY/-/-/-/-]/- 
DID: 0003-000E-00000003, short-term DID: 0000-0000-00000000 
txn branch: 0 
oct: 0, prv: 0, sql: 0, psql: 0, user: 0/SYS 
last wait for 'latch free' blocking sess=0x0 seq=57724 wait ti mez8333 seconds since 


wait started=352 
address=70000001000f4b0, number=56, tries=439 
Dumping Session Wait History 
or ‘latch free’ countzl wait ti mez8333 
address-70000001000f4b0, number=56, tries=439 
or ‘latch free’ count=1 wait_time=292977 
address=70000001000f4b0, number=56, tries=438 
or ‘latch free’ count=1 wait_time=292977 
address=70000001000f4b0, number=56, tries=437 
or ‘latch free’ countzl wait_time=292977 


从 trace 文 件 中 可 以 看 出 , 节点 3 AY LMS 进程 出 现 了 门 锁 等 待 , 该 门 锁 的 编号 是 56, 通过 查 
ij VSLATCHNAME 视图 ， 我 发 现 这 个 门 锁 是 OS process: request allocation。 而 之 前 的 消息 说 明 
接收 新 连接 超时 。 

(422018 <- 475916)SKGXPDOCON: can't accept new connections under timed wait context 

SKGXDOCON 是 RAC INTERCONNECT 通信 层面 的 模块 。 这 说 明 在 故障 期 间 ，RAC 
INTERCONNECT 通信 出 现 了 异常 。 于 是 , 我 检查 了 NMON 报告 中 的 NET 通信, 如 图 16-5 所 示 。 

上 面 的 数据 没有 出 现 异 稼 ， 因 此 不 是 网 络 阻塞 导致 了 问题 。 接 下 来 ， 进 一 步 分 析 CPU 等 资 
源 的 使 用 情况 ， 如 图 16-6 所 示 。 
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在 这 张 图 中 我 也 没有 发 现 异常 。 在 时 间 点 18:00 后 ， 系 统 负载 并 没有 增加 ， 反 而 VO ARK 
KEM, 这 是 因为 下 班 后 使 用 系统 的 人 在 减少 。 至此, 分析 工 作 似 乎 陷入 了 僵局 ， 于 是 我 询问 了 
DBA, 在 故障 前 是 否 进行 过 特殊 操作 。 后 来 得 知 在 6 点 40 分 左右 , DBA 曾 通过 SCP 在 两 个 节点 
间 复 制 了 一 个 几 十 GB 的 文件 , 但 开始 没 多 久 ， 系 统 就 宕 机 了 。 这 条 线索 让 我 眼前 一 亮 ， 立即 检 
查 了 NMON 报告 中 的 换 页 信息 ， 如 图 16-7 所 示 。 
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我 们 可 以 看 到 一 个 明显 的 问题 ， 在 时 间 点 18:42 附近 ， 系 统 出 现 了 十 分 严重 的 换 页 现象 。 这 
足以 导致 LMS7 进程 无 法 获取 到 CPU 资源 ， 从 而 产生 网 络 通信 超时 。 经 过 检查 ， 我 发 现 这 人 台 服 
务 器 的 MAXPERM9% 人 参数 设置 为 80%。 就 这 样 绕 了 一 大 圈 ， 问 题 又 回 到 了 MAXPERM9% 人 参数 ， 
看 来 著名 的 IBM 红皮书 真是 害 人 不 浅 啊 。 
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这 是 一 套 4 节点 的 RAC AZ, 4А I9 日， 由 于 一 个 新 上 线 的 业务 模块 出 现 问题 ， 导 致 一 个 
节点 负载 特别 高 。 业 务 部 门 发 现 问题 后 ， 马 上 杀 掉 了 这 个 应 用 。 但 在 故障 处 理 期 间 ， 这 个 实例 宕 
机 了 。 由 于 这 套 系 统 并 未 根据 SERVICE NAME 划分 应 用 的 实例 ， 而 是 直接 通过 IP 地址 连接 的 。 
此 该 实例 宕 机 后 , 其 应 用 无 规律 地 转移 到 了 其 他 节点 ,而 这 个 节点 上 存在 一 些 很 大 的 批 处 理 作 
业 ， 因 此 应 用 故障 转移 (failover ) 后 由 于 DRM 机 制 的 存在 ， 出 现 了 严重 的 争 用 ， 从 而 导致 系统 
的 性 能 下 降 , 其 中 有 一 个 实例 基本 无 法 使 用 。 客户 的 DBA 发 现 问 题 后 , 想 关闭 并 重启 这 个 实例 ， 
但 重启 了 10 多 分 钟 也 没 能 打开 。 于 是 才 联 系 我 ， 希 望 我 马上 到 现场 帮 他 们 处 理 。 

在 我 到 达 现 场 前 , 那个 实例 已 经 打开 了 。 但 由 于 故障 转移 的 问题 ， 其 他 实例 又 开始 出 现 问题 
了 。 于 是 我 建议 先 暂 停 应 用 ,再 重启 实例 , 将 有 问题 的 实例 全 部 重启 一 遍 。 经 过 1 个 多 小 时 的 工 
作 ， 我 们 终于 在 下 午 4 点 多 恢复 了 系统 的 运行 。 没 有 影响 5 点 到 7 点 的 业务 高 峰 。 

系统 恢复 后 ,我 们 简单 地 分 析 了 故障 的 原因 。 毫 无 疑问 ， 某 个 实例 穷 机 后 应 用 的 无 序 切 换 是 
导致 所 有 节点 故障 的 主要 原因 。 这 是 由 于 应 用 没有 使 用 SERVICE, NAME 所 导致 的 , 目前 暂时 还 
没有 解决 方案 ， 如 果 修 改 连接 池 的 配置 ， 将 涉及 300 多 个 配置 项 ,调整 工作 量 太 大 ， 开 发 部 门 也 
拒绝 修改 。 本 次 故障 的 处 理 过 程 超过 两 个 小 时 ， 是 因为 系统 启用 了 DRM， 导 致 实例 重启 十 分 组 
慢 。 为 了 确保 这 种 情况 不 会 再 次 出 现 ， 我 建议 他 们 关闭 DRM， 但 由 于 完成 此 操作 需要 重启 所 有 
节点 ， 所 以 我 们 仅 修 改 了 SPFILE 的 参数 ， 等 待 下 一 个 停机 窗口 进行 重启 。 

本 来 以 为 这 次 故障 算是 处 理 完了 , 由 于 在 整个 过 程 中 业务 没有 完全 中 断 ,， 关 键 业 务 也 能 时 断 
时 续 地 进行 ,因此 在 客户 那里 并 没有 造成 太 大 的 影响 。 所 以 客户 对 故障 分 析 报 告 催 得 并 不 是 很 紧 。 
但 正在 我 考虑 何 时 去 递交 分 析 报 告 的 时 候 ， 突 然 出 大 事 了 。 

两 天 后 ， 也 就 是 4 月 21 日 下 午 1 点 10 分 左右 , 系统 响应 时 间 变 慢 ，4 个 实例 均 出 现 挂 起 
现象 。 我 到 达 现 场 时 ， 系 统 已 经 从 较 慢 变 为 基本 不 可 用 了 ， 客 户 的 DBA 正在 尝试 关闭 所 有 的 
实例 。 

不 过 在 关闭 数据 库 的 时 候 遇 到 了 麻烦 ， 在 服务 器 上 使 用 sysdba 账号 无 法 登录 数据 库 ， 因 此 
也 就 无 法 正常 关闭 实例 ， 只 能 通过 kill 命令 杀 掉 SMON 进程 强制 关闭 数据 库 。 

但 这 个 过 程 并 不 顺利 , 除了 通过 KILL SMON 命令 成 功 关闭 节点 4 外 , 其 他 节点 的 SMON 进 
程 均 无 法 杀 掉 ,最 终 我 们 只 能 选择 重启 服务 器 。 在 未 查 明 故障 原因 前 , 为 了 使 数据 库 重 启 后 不 再 
出 现 类 似 问题 ， 我 建议 对 已 经 关闭 实例 的 节点 4 也 进行 重启 。 

重启 后 ， 系 统 恢复 正常 ， 由 于 事先 修改 了 DRM 的 配置 ， 因 此 本 次 重启 的 时 间 大 幅 缩短 。 关 
Й) DRM 的 设想 是 基于 本 系统 做 了 一 定 程度 的 应 用 分 区 ， 两 个 实例 中 共享 数据 一 般 只 有 一 个 节点 
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变更 ， 其 他 节点 都 是 只 读 状 态 ， 平 时 业务 高 峰 期 4 个 节点 之 间 的 RAC INTERCONNECT 通信 流 
量 也 控制 在 5~8MB 之 间 。 关闭 DRM 可 以 使 系统 更 为 稳定 , 不 会 因为 应 用 切换 错误 而 引发 严重 
的 性 能 问题 。 

由 于 3 天 内 发 生 了 两 次 重大 的 系统 故障 , 因此 客户 的 领导 要 求 彻 查 此 事 。19 日 的 故障 被 推 到 
TH E. 勉强 也 说 得 过 去 , 不 过 此 故障 虽然 是 应 用 导致 的 , 但 DRM 也 是 推波助澜 的 主要 因素 。 

WR DRM 没有 启用 ， 就 算 系统 会 变 慢 ， 也 不 至 于 出 现 不 可 用 的 情况 。 

下 午 的 会 议 中 , 我 简单 地 向 数据 中 心 的 领导 汇报 了 故障 的 处 理 情况 。 数 据 中 心 主任 希望 我 们 
能 够 确定 问题 已 经 解决 ,并且 确保 类 似 的 宕 机 故障 不 会 再 次 出 现 。 我 考虑 了 一 下 告诉 他 ,目前 问 
题 还 没有 定位 ， 所 以 我 无 法 保证 问题 已 经 解决 了 。 由 于 4 个 节点 都 出 现 了 故障 ,因此 故障 定位 相 
对 简单 , 但 由 于 需要 分 析 的 资料 很 多 , 整个 过 程 可 能 需要 3 ~5 天 的 时 间 。 我 们 已 经 关闭 了 DRM， 
但 是 否 奏效 还 有 待 观察 ， 在 此 期 间 ， 我 们 必须 加 强 对 系统 的 监控 。 

会 议 结束 后 , 我 们 立即 开始 对 本 次 故障 进行 分 析 。 首 先 我 和 客户 的 运 维 小 组 一 起 明确 了 本 次 
问题 分 析 工 作 的 主要 内 容 ,， 包括 小 型 机 、 存 储 、 操 作 系 统 、 网 络 和 数据 库 几 个 层面 ， 其中， 存储 
和 小 型 机 的 日 志 需 要 由 系统 组 去 分 析 , 网 络 日 志 由 网 络 组 进行 分 析 , 而 我 们 的 重点 工作 是 分 析 操 
作 系 统 和 数据 库 。 

很 快 系统 组 就 有 了 反馈 信息 ， 小 型 机 和 存储 并 无 报错 ,网 络 组 的 排查 也 没有 发 现任 何 疑点 。 
我 检查 了 操作 系统 和 HACMP 程序 的 日 志 ， 也 没有 发 现 明显 的 错误 信息 。 男 外 ， 也 没有 在 故障 
点 前 后 的 crsd 和 cssd 日 志 中 发 现 有 价值 的 线索 。 于 是 我 们 的 分 析 重 点 就 放 在 数据 库 的 日 志 分 析 
ET, 

ALERT LOG 日 志 中 并 没有 有 价值 的 信息 ，PMON、SMON LMD, LMS 进程 的 日 志 中 也 没 
有 疑点 。 幸运 的 是 , 4 个 节点 的 diag 中 都 存在 一 个 系统 状态 转 储 , 这 是 在 杀 掉 smon 进程 时 ，diag 
进行 的 转 储 操作 。 于 是 我 们 通过 ass109.awk 脚本 对 这 4 个 trace 文件 进行 了 分 析 。 得 到 的 报告 让 
我 们 大 吃 一 惊 ，4 个 节点 的 块 状态 信息 都 是 很 长 的 一 串 ， 而 不 是 通常 的 几 个 或 十 几 个 。 

Resource Holder State 

Enqueue PS-00000001-00000E0F 22? Blocker 

Enqueue US-000000B1-00000000 ??? Blocker 

Enqueue CF-00000000-00000000 18: waiting for 'RDBMS ipc message 


Enqueue TX-02040011-000248F0 112: waiting for 'gc buffer busy 
Enqueue TX-00F90016-000ED217 75: waiting for 'gc buffer busy' 


Enqueue TX-01EF0023-0002504A 248: waiting for 'gc current request' 
Enqueue TX-01D3001B-0002998E 504: 504: is waiting for 75: 
Enqueue TX-01EB0000-00024C39 500: 500: is waiting for 75: 
Enqueue TX-01D40015- 00029004 511: 511: is waiting for 75: 
Enqueue TX-01050019-0012807C 408: 408: is waiting for 75: 
Enqueue TX-00040000-0026D455 87: 87: is waiting for 75: 
Enqueue TX-014A0024-00095BBD 470: 470: is waiting for 75: 
Enqueue TX-01710004-0007263F 510: 510: is waiting for 75: 
Enqueue TX-01820020-0005F1B1 464: 464: is walting for 75: 
Enqueue TX-00150025-002F2748 164: waiting for 'gc buffer busy 
Enqueue TX-0006002A-0020C4D7 140: waiting for 'gc buffer busy 
Enqueue TX-002A0015-0027DD88 195: 195: is waiting for 75: 


Enqueue TX-00D30010-00200A5D 125: waiting for 'gc buffer busy 
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Enqueue TX-01420025-000AC2F0 212: 212: is waiting for 75: 
Enqueue TX-001C0026-00309D98B 383: 383: is waiting for 75: 
Enqueue TX-013A0003-000A5786 463: 463: is waiting for 75: 
Enqueue TX-01C80011-0002B04C 499: 499: is waiting for 75: 
Enqueue TX-00320005- 002C1B48 109: waiting for 'gc buffer busy 
Enqueue TX-01AE0001-000372B4 469: 469: is waiting for 75: 
Enqueue TX-01A20017-0003D26E 314: 314: is waiting for 75: 
Enqueue TX-02020014-00022D0D 227: waiting for ‘gc buffer busy 
Enqueue TX-0026002A- 001CCA2B 119: waiting for 'gc buffer busy 
Enqueue TX-00F40015-0013229C 377: 377: is waiting for 75: 
Enqueue TX-02080026-0001E8FF 384: 384: is waiting for 75: 
Enqueue TX-0183002C-000590C9 107: waiting for 'gc buffer busy 
Enqueue TX-003C0004-002059FF 85: 85: is waiting for 75: 
Enqueue TX-01960019-000347EC 466: 466: is waiting for 75: 
Enqueue TX-00CC0023-00244556 223: 223: is waiting for 75: 
Enqueue TX-00E2001D-001936FC 153: 153: is waiting for 75: 
Enqueue TX-01AB0001-00037A70 100: waiting for 'gc buffer busy 
Enqueue TX-00CA001E-00260EFB 335: 335: is waiting for 75: 
Enqueue TX-011A0021- 000DDC98 117: waiting for 'gc buffer busy 
Enqueue TX-00EF002F-00168502 380: 380: is waiting for 75: 
Enqueue TX-01870008-0002CC51 376: 376: is waiting for 75: 
Enqueue TX-01CA001C- 0002D335 336: 336: is waiting for 75: 
Enqueue TX-00DF000E-00197E77 225: waiting for 'gc buffer busy 
Enqueue TX-02050028-00022001 490: 490: is waiting for 75: 
Enqueue TX-0106001D-00139EA4 256: waiting for 'gc current request 
Enqueue TX-020F000E-0003831F 416: 416: is waiting for 75: 
Enqueue PS-00000001-00000E0E ??? Blocker 

Enqueue TX-01D20024-0002723B 390: 390: is waiting for 75: 
Enqueue TX-0018000B- 002D7BFE 506: 506: is waiting for 75: 
Enqueue TX-00C00005-00180890 423: 423: is waiting for 75: 
Enqueue ТХ- 0176002А- 00065ВА7 131: waiting for 'gc buffer busy 
Enqueue TX-00F9002F-000ED242 75: waiting for 'gc buffer busy 
Enqueue TX-01C00001-000318E4 58: 58: is waiting for 75 
Enqueue TX-01A5002A- 00039637 501: 501: is waiting for 75: 
Enqueue TX-01670021-000836C4 186: 186: is waiting for 75: 
Enqueue TX-01910019- 00046348 496: 496: is waiting for 75: 
Enqueue TX-01300020-000AE76D 460: 460: is waiting for 75: 
Enqueue TX-01D60018-000239E1 402: 402: is waiting for 75: 
Enqueue TX-02110008-0001E839 104: waiting for 'gc buffer busy 
Enqueue TX-01A9000B-0003578E 468: 468: is waiting for 75: 
Enqueue TX-0119002C- 00009025 498: 498: is waiting for 75: 
Enqueue TX-01F70021-000215D0 426: 426: is waiting for 75: 
Enqueue ТХ- 01С0001А- 00023733 352: 352: is waiting for 75: 
Enqueue TX-00E70020-0020DCB1 216: 216: is waiting for 75: 
Enqueue TX-01A6002F-0003C312 165: waiting for 'gc buffer busy 
Enqueue TX-00C20029- 001BEBCO 163: 163: is waiting for 75: 
Enqueue TX-014E0020-000796DD 333: 333: is waiting for 75: 
Enqueue TX-00CF0022-001DFE37 110: 110: is waiting for 75: 
Enqueue TX-02030023-00023F0A 150: waiting for 'gc buffer busy 
Enqueue TX-01C50014- 0002ED41 378: 378: is waiting for 75: 
Enqueue TX-01890018- 0004EF95 515: 515: is waiting for 75: 
Enqueue TX-00380021-002090C8 305: 305: is waiting for 75: 
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情 。 


的 等 待 。CKPT 进程 在 等 待 IPC 消息 。 


Enqueue ТХ- 0160001А- 000A5D5F 
Enqueue ТХ- 01Е7000В- 00024852 
Enqueue ТХ- 00080023- 0029Е396 
Enqueue ТХ- 000А000А- 007125АВ 
Enqueue ТХ- 019Е0023- 00044096 
Enqueue TX-012E0022-000AF5D3 
Enqueue TX-01F80000-00021665 
Enqueue TX-013B0002-00098D23 
Enqueue TX-00BF0018-0019DFA9 
Enqueue TX-01680000-0008A8B1 
Enqueue TX-019A0001-00042D84 
Enqueue ТХ- 01АА001С- 00035569 
Enqueue TX-01B2001D- 00038628 
Enqueue TX-01ECOO02bE-000240DB 
Enqueue TX-003A0001- 001FBA28 
Enqueue TX-00240029- 001F0BB4 
Enqueue TX-01610016-00099F4F 
Enqueue TX-01990016-0003FFC3 
Enqueue ТХ- 00090000- 0029BEBO 
Enqueue TX-01A80012-000360FF 
Enqueue TX-01A10016-0003D84B 
Enqueue TX-016E0011-00074FAC 
Enqueue FB-00000006-E70AAFOC 
Enqueue FB-00000006-89C45E0C 
Enqueue FB-00000006-E64ABA0D 
Enqueue FB-00000006- B9CAABBE 
Enqueue FB-00000006- B9CAAB8F 
LOCK: hand! e=700000b8ee38e28 
LOCK: hand! e=700000b8ee38e28 
LOCK: handlez700000b8ee38e28 
Enqueue FB-00000006- B9CAAB90 
Enqueue FB-00000006- BAOABF89 


waiting 
458: is 
415: is 
222: is 
385: is 
393: is 
155: is 
401: is 
210: is 
waiting 
waiting 
waiting 
waiting 
Blocker 
waiting 
Blocker 


for 'gc buffer busy 
waiting for 75: 
waiting for 75: 
waiting for 75: 

or 'gc current request 
waiting for 75: 

or 'gc buffer busy 
or 'gc buffer busy 
waiting for 75: 

or 'gc buffer busy 
or 'gc buffer busy 
or 'gc buffer busy 


waiting for 75: 
waiting for 75: 
waiting for 75: 
waiting for 75: 
waiting for 75: 
waiting for 75: 
waiting for 75: 
waiting for 75: 


or 'gc buffer busy 
or 'gc current request 
or 'log file sync' 
or 'log file sync' 


or 'log file sync' 


68: is waiting for Enqueue US-00000081-00000000 
69: is waiting for Enqueue US-00000081-00000000 


waiting 
waiting 
Blocker 


or 'SQL*Net message from client 
or 'log file sync' 


在 这 种 情况 下 ， 逐 个 排查 阻塞 数据 (blocker ) 的 工作 量 非常 大 ， 而 且 似 乎 是 吃力 不 讨好 的 事 
一 般 来 说 ， 遇 到 这 种 情况 ， 应 该 重点 关注 几 个 核心 后 台 进 程 。 通 过 对 trace 文件 的 分 析 ， 我 
们 发 现实 例 1 的 CKPT 进程 (PROCESS 18) ЖЕЗ CF 锁 ， 并 且 在 等 待 IPC 消息 ，SMON 进程 在 


等 待 DFS LOCK HANDLE 锁 。 


实例 2 存在 大 量 的 GC BUFFER BUSY 等 待 事件 , 在 系统 状态 转 储 中 发 现 了 1096 个 GC 方面 


实例 3 存在 1600 多 个 的 GC 等 竺 和 SQ 锁 的 等 待 , 同时 CKPT 进程 持 有 CF Bit, 并 在 等 待 IPC 
消息 ，SMON 进程 在 等 待 DFS LOCK HANDLE fii, 


实例 4 的 持 有 相对 比较 简单 


Resource Holder 


Latch 70000001000elc8 
Latch 70000001000cea8 
Latch 700000b5c300798 
Enqueue ХА- 00000004- 00000000 
Enqueue DR-00000000- 00000000 


Rcache obj ect =700000b8a9241f 8 


22? 
22? 
22? 
18: 
22? 
22? 


State 

Blocker 
Blocker 
Blocker 


Self-Deadlock 


Blocker 
Blocker 
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Enqueue CF-00000000-00000000 18: Self-Deadlock 
Latch 700000b5ef19890 526: 526: is waiting for 526: 604: 846: 1077: 1102 
Latch 700000b5ef 19890 604: 604: is waiting for 526: 604: 846: 1077: 1102 
Latch 700000b5ef 19890 846: 846: is waiting for 526: 604: 846: 1077: 1102 
Latch 700000b5ef19890 1077: 1077: is waiting for 526: 604: 846: 1077: 1102 
Latch 700000b5ef19890 1102: 1102: is waiting for 526: 604: 846: 1077: 1102 
Latch 700000b69b3c7f0 ??? Blocker 
Latch 700000b5c3d5c40 777 Blocker 
Enqueue FB-00000073-DD42440A 82: waiting for ‘log file sync' 
Enqueue TX-00810029-000AF301 44: 44: is waiting for Latch 70000001000cea8 
Enqueue US-000000B1- 00000000 325: last wait for ‘latch: cache buffers chains 
Latch 700000b5e196160 ??? Blocker 
Latch 700000b6970fd80 777 Blocker 
Latch 700000b69e24580 777 Blocker 
Latch 700000b6c7d4b80 777 Blocker 


在 上 面 的 数据 中 我 们 看 到 了 一 条 十 分 抢眼 的 信息 : 

Enqueue XR-00000004-00000000 18: Self-Deadlock 

XR 锁 居 然 出 现 了 自 死 锁 ， 而 自 死 锁 的 进程 是 18 号 , 也 就 是 CKPT 进程 , 通过 阅读 CKPT 进 
程 的 进程 状态 转 储 (process state dump )， 我 们 发 现 是 CF 锁 和 XR 锁 的 自 死 锁 。 

从 上 面 的 信息 来 看 ,似乎 实例 4 是 锁 死 所 有 4 个 节点 的 “元 XI”, 其 他 进程 在 和 实例 4 的 CKPT 
进程 进行 信息 同步 时 产生 了 锁 死 的 现象 。 如 果真 是 这 样 ， 那 么 故障 出 现 前 后 ， 应 该 存在 大 量 的 
DFS LOCK HANDLE 等 待 ， 而 且 等 待 的 原因 应 该 和 CKPT 进程 或 者 CF 锁 有 关 。 如 果 我 们 在 处 理 
一 套 % 或 者 更 早期 版 本 的 数据 库 ， 那 么 就 只 能 依靠 猜测 或 者 在 trace 中 一 点 点 地 查找 可 能 存在 的 
蛛丝马迹 。 幸 运 的 是 ,我们 目前 分 析 的 是 一 套 10g 版 本 的 系统 ， 因 此 可 以 通过 ASH 数据 进一步 
定位 。 

通过 检查 ASH 数据 , 我 们 发 现在 故障 发 生前 , DFS LOCK HANDLE 锁 等 待 的 现象 十 分 严重 ， 
而 且 所 有 的 DFS LOCK HANDLE 锁 的 ID2 都 是 3， 根 据 相 关 资 料 (C ORACLE RAC 日 记 》 一 书 
中 有 关于 DFS LOCK HANDLE 锁 的 详细 介绍 ， 如 果 大 家 有 兴趣 也 可 以 查阅 MOS 上 的 相关 内 容 ， 
这 里 就 不 详细 介绍 该 锁 的 ID2 的 含义 了 ), 我们 知道 ID2=3 意味 着 “DBWR syncronization of SGA 
with control file”， 这 是 一 个 和 控制 文件 有 关 的 等 待 ， 含 义 是 DBWR 要 同步 SGA 中 的 控制 文件 信 
息 以 及 控制 文件 上 的 控制 文件 信息 。 

似乎 我 们 已 经 找到 了 导致 4 个 节点 全 部 出 现 故 障 的 节点 一 一 节点 4, 而 且 也 分 析 清 楚 了 DFS 
LOCK HANDLE 的 等 待 原因 ， 即 都 在 等 待 将 SGA 同步 到 控制 文件 。 但 其 实 离 找到 真正 的 “元 区 ” 
还 有 很 长 的 路 。 

通过 前 面 的 分 析 我 们 发 现 ， 系统 中 存在 大 量 的 DFS LOCK HANDLE 等 待 ， 这 类 等 待 在 RAC 
环境 中 是 一 种 跨 实例 (cross instance) 的 等 待 ， 主 要 是 在 等 待 其 他 实例 完成 某 项 工作 。 我 们 从 事 
故 点 开始 向 前 分 析 ， 在 采集 大 量 的 AWR 报告 ， 并 进行 了 更 深入 地 分 析 后 发 现 ， 本 系统 正常 情况 
下 半 小 时 采样 周期 内 的 AWR 报告 中 的 DES HANDLE LOCK 等 待 次 数 大 约 为 15 000 Ix, 平均 等 
待 时 间 为 1 毫秒 ; 而 故障 前 平均 半 小 时 的 DFS LOCK HANDLE 等 待 次 数 达到 235 万 次 以 上 , SÉ 
均 每 次 的 等 待 时 间 为 1 毫秒 。 数 据 库 重 启 前 的 数据 如 下 : 
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Avg 
%Time Total Wait Wait Waits 
Event Waits -outs Time (5) ( ms ) [txn 
DFS lock handle 2,352,423 .0 1,374 1 422.1 
数据 库 重 启 后 的 数据 如 下 : 
Avg 
%Time Total Wait wait Waits 
Event Waits -outs Time (5) (ms) /txn 
DFS lock handle 15,679 .0 11 1 2532 


从 这 两 组 数据 的 对 比分 析 可 以 看 出 ，19 日 数据 库 重启 后 ，DFS LOCK HANDLE 等 待 次 数 均 
在 200 ~ 350 万 次 之 间 ; 而 19 日 数据 库 重 启 前 ，DEFS LOCK HANDLE 等 待 次 数 处 于 正常 水 平 : 


Avg 
%Time Total Wait wait Waits 
Event Waits -outs Time (s) ms ) [txn 
DFS lock handle 9,346 .0 5 1 0.7 


从 19 日 故障 前 、 故 障 处 理 完毕 ， 以 及 21 日 系统 重启 后 的 DFS 相关 等 待 的 比较 来 看 ，19 日 
故障 处 理 完毕 到 21 日 系统 故障 前 的 DFS 相关 等 待 异 常 ， 超 过 正常 指标 100 倍 以 上 。 从 这 一 点 可 
以 看 出 ,在 19 日 系统 故障 后 ， 我 们 对 几 个 实例 都 进行 了 重启 ， 但 是 没有 统一 停机 重启 。 在 此 期 
E, 应 用 服务 器 连接 池 的 故障 转移 出 现 了 凑 乱 , 虽然 这 种 无 序 的 故障 转移 最 终 得 到 了 控制 , 但 在 
跨 实例 方面 仍 处 于 送 乱 状态 。 此 后 系统 一 直人 处 于 带 病 工作 状态 , 最 终 导致 平时 业务 量 最 小 的 节点 
4 出 现 了 CF 锁 和 XR 锁 的 自 死 锁 ， 从 而 引发 了 更 大 的 系统 故障 。 

由 于 节点 4 的 CKPT 进程 出 现 了 自 死 锁 ， 使 得 节点 4 被 挂 起 ， 其 他 节点 由 于 等 待 节点 4 的 
CF 锁 也 被 挂 起 。 导 致 CKPT 进程 出 现 自 死 锁 的 主要 原因 是 DFS LOCK HANDLE 等 待 十 分 严重 。 
系统 中 存在 大 量 的 GCS/GES 相关 等 待 。 

也 就 是 说 ，21 日 的 系统 故障 和 19 日 的 故障 是 有 联系 的 ， 前 者 是 后 者 的 延续 。19 日 系统 故障 
后 ， 大 多 数 实例 都 进行 了 重启 ， 但 是 为 了 确保 关键 业务 能 够 尽快 恢复 ， 各 个 实例 是 独立 重启 的 ， 
并 未 进行 统一 关闭 、 统 一 重启 操作 。 由 于 实例 重启 时 ,应 用 在 大 量 实例 间 漂 移 ， 因 此 产生 了 多 次 
由 应 用 漂移 导致 的 “ 压 死 ” 某 个 实例 的 情况 。 整 个 实例 重启 过 程 持 续 了 数 小 时 ， 在 这 段 时 间 内 应 
用 漂移 现象 时 有 发 生 。 重 启 完 成 后 ， 跨 实例 就 一 直 处 于 不 正常 状态 ，DFS LOCK HANDLE 等 待 
数量 从 正常 的 10 000 ~ 15 000 次 上 升 为 000 000~3500000 次 。 因 此 ，21 日 的 故障 是 问题 积累 
到 一 定 程度 时 系统 的 爆发 。 

另外 一 个 方面 ， 由 于 跨 实例 存在 问题 ， 从 而 导致 GCS/GES HERE FI, GCS 等 待 大 量 产生 ， 
由 于 应 用 软件 在 多 实例 数据 共享 方面 的 开销 比较 大 ,而 DRM 功能 在 10g 版 本 中 又 是 默认 启用 的 ， 
因此 使 得 GCS 方面 出 现 了 严重 的 争 用 ，GCS FLUSH 等 待 大 幅 增 加 。 这 样 就 引发 了 bug 6418420. 
bug 8215444 这 类 问题 ， 从 而 导致 CKPT 出 现 自 死 锁 ， 并 最 终 导 致 4 个 实例 全 部 挂 起 。 

针对 上 述 分 析 的 结论 ， 我 们 提出 了 一 系列 的 优化 方案 : 
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(1) 建议 关闭 DRM (21 日 重启 前 已 经 实施 )。 

(2) 优化 应 用 , 减少 GCS/GES 争 用 。 

(3) 当 某 个 实例 发 生 故 障 时 ， 尽 可 能 避免 应 用 在 实例 间 的 无 序 切 换 ， 并 避免 作业 在 错误 的 实 
例 上 执行 。 

(4) 目前 系统 的 VO MERE ME, 平均 USER IO 成 本 在 高 峰 期 超过 30 毫秒 ( 正常 情况 应 该 小 
于 10 毫秒 ), 这 样 会 增加 GCS/GES 争 用 , 建议 对 IO 系统 进行 扩容 和 优化 ,从 而 提高 VO FAB 
的 总 体 性 能 。 

(5) 建议 优化 PARALLEL Instance GROUPS 参数 的 设置 , 避免 跨 实 例 的 并 行 查 询 ( 故障 时 节 
点 3 存在 跨 四 个 实例 的 并 行 查 询 )， 在 类 似 的 OLTP 系统 中 ， 跨 实例 并 行 查询 可 能 导致 严重 的 性 
能 问题 。 

(6) 实例 1 上 存在 较 多 的 ITL 等 待 ， 如 果 该 等 待 大 量 存 在 于 GCS/GES 等 待 较 高 的 系统 中 ， 可 
能 会 导致 系统 挂 起 。 建 议 对 相关 表 和 索引 的 INITTRANS 参数 进行 优化 。 

(7) 实例 3 上 存在 较 多 的 ENQ: SQ 等 待 ， 在 RAC 环境 中 ，SQ 等 待 会 增加 GCS/GES 争 用 的 
机 会 ,严重 时 可 能 会 导致 系统 挂 起 。 建 议 优化 相关 的 序列 参数 , 加 大 缓存 , 尽 可 能 使 用 NOORDER 
选项 。 

(8) 建议 针对 bug 6418420. bug 8215444 更 新 补丁 。 由 于 bug 6418420 在 AIX FF 10.2.0.4 № 
本 上 没有 ONE-OFF 补丁 ， 而 该 修复 包含 在 PSU 10.2.0.4.1 及 以 上 的 版 本 中 ， 因 此 ， 建 议 将 PSU 
升级 到 10.2.0.4.4 或 者 10.2.0.4.5。 

至 此 ,这 个 案例 就 介绍 完了 ,在 进行 了 上 述 调整 后 ,这 套 系统 没有 再 次 出 现 类 似 的 问题 。 可 
能 有 些 朋 友 看 到 这 里 会 有 些 迷 惑 ， 如 此 “ 故 私 烈 烈 ” 的 案例 怎么 就 这 样 平淡 地 收场 了 呢 ， 好 像 也 
并 没有 定位 到 问题 的 真正 根源 啊 ? 实际 上 ， 上 述 优 化 建议 主要 针对 GC 方面 的 性 能 问题 ， 对 于 如 
此 复杂 的 宕 机 故障 , 想 要 将 其 完全 定位 到 一 个 很 小 的 点 上 几乎 是 不 可 能 的 。 虽然 最 终 的 原因 可 能 
就 是 在 某 个 点 上 ,但 由 于 DBA 的 能 力 、 分 析 投 入 的 成 本 以 及 分 析 所 需 的 资料 有 限 ， 在 绝 大 多 数 
情况 下 都 无 法 十 分 精确 地 定位 是 否 就 是 某 个 Bug 或 者 配置 导致 了 问题 ,不 过 我 们 可 以 大 致 定位 到 
一 个 较 大 范围 上 , 通过 对 这 个 范围 的 分 析 ， 提出 一 套 综合 性 的 解决 方案 , 这 就 是 老 白 经 常 提 到 的 
“AA”. 

这 两 个 Bug 可 能 是 导致 问题 的 “元 多”， 也 可 能 是 “受害 者 ”， 简 单 地 将 问题 推 给 Bug 是 很 
不 负责 任 的 做 法 。 实 际 上 ， 出 现 问题 的 最 终 根 源 还 是 GC 和 DRM， 因 此 老 白 提出 了 一 套 综合 性 
的 解决 方案 。 从 实际 的 效果 来 看 ， 对 问题 点 的 定位 还 是 比较 准确 的 , 根据 问题 定位 所 提出 的 解决 
方案 也 是 较为 合理 的 ， 调 整 后 系统 的 表现 就 是 最 好 的 证 明 。 
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ORA-600 是 一 种 十 分 常见 的 错误 ， 很 多 DBA 都 会 将 它 和 Bug 联系 在 一 起 。 实 际 上 ， 产 生 
ORA-600 的 原因 非常 复杂 ， 不 能 简单 地 归结 到 某 个 Bug 上 ， 而 且 并 不 是 所 有 的 ORA-600 错误 者 
能 和 Bug 挂钩 。 本 节 将 介绍 几 个 关于 ORA-600 的 分 析 案例 ， 通 过 这 些 案例 ， 我 们 可 以 学 习 到 如 
何 使 用 Metalink 来 分 析 这 类 问题 。 
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ORA-600[12700] 的 含义 是 索引 中 的 ROWID 指向 了 一 个 不 存在 的 行 。 如 果 我 们 通过 索引 查找 
某 条 记录 ， 而 索引 中 的 某 个 ROWID 指向 的 行 在 数据 块 中 并 不 存在 ， 那 么 就 会 出 现 ORA-600 
[12700] 错 误 。 关 于 ORA-600 [12700] 错 误 的 详细 解释 可 以 参考 Metalink 文档 ORA-600 [12700] 
"Index entry Points to Missing ROWID” [ID 28229.1], 在 这 里 就 不 过 多 介绍 了 。 简单 地 说 , ORA-600 
[12700] 错 误 是 由 数据 不 一 致 、 索 引 损 坏 或 表 数 据 损坏 引起 的 ,比如 , 实例 宕 机 或 者 从 旧 数 据 文件 
进行 不 完全 恢复 后 被 强制 打开 ， 数 据 文件 中 存在 不 一 致 。 

磁 到 这 类 问题 该 如 何 解决 呢 ? 分 析 ORA-600 [12700] 错 误 时 ，Metalink 文档 Resolving an 
ORA-600 [12700] error in Oracle 8 and above [ID 155933.1] 是 一 份 很 好 的 参考 资料 。 这 份 文档 提出 
了 下 面 的 分 析 步 又 : 

(D 分 析 包 含 ORA-600 [12700] 错 误 的 trace 文件 。 

(2) 找到 损坏 的 数据 库 对 象 ， 并 验证 该 对 象 是 否 损坏 。 

(3) 找到 损坏 的 索引 。 

(4) 如 果 确 认 是 索引 损坏 ， 就 重建 索引 。 

(5) 如 果 是 由 数据 块 故障 导致 的 ， 请 参考 Note:28814.1 "Handling Oracle Block Corruptions in 
Oracle7/8/8i” 文 档 进 行 处 理 。 

(6) 如 果 索 引 和 数据 均 未 损坏 ， 那 么 可 能 是 一 致 性 读 存 在 问题 。 

首先 我 们 可 以 在 ALERT LOG 日 志 中 找到 trace 文件 ， 打 开 trace 文件 可 以 看 到 类 似 的 信息 : 


*** 2001-05-29 18:59:53.735 

ksedmp: internal or fatal error 

ORA-00600: internal error code, arguments: [12700], [2997], [16778259],... 
Current SQL statement for this session: 

select * from xxxxx where mmmmmz' yyy' 
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通过 Current SQL 我 们 可 以 定位 出 现 问题 的 表 。 不 过 很 多 时 候 ，Current SQL 可 能 是 包含 多 表 
连接 的 复杂 SQL, 或 者 trace 文件 根本 没有 指出 Current SQL ， 这 种 情况 下 ，7155933.7 这 份 文档 后 
面 的 部 分 提供 了 一 个 脚本 ， 该 脚本 能 够 创建 两 个 用 于 分 析 ORA-600 [12700] 的 工具 一 一 oerr12700 
All oerr12700diag。 这 两 个 工具 可 以 帮助 我 们 定位 出 现 故障 的 行 。 使 用 oerr12700 分 析 后 ， 我 们 还 
可 以 用 dbv 或 者 ANALYZE 命令 来 分 析 表 数据 是 否 存在 问题 。 

如 果 表 数据 没有 问题 ， 那 么 就 说 明 可 能 是 索引 损坏 了 。 这 时 可 以 使 用 ANALYZE TABLE 
VALIDATE STRUCTURE CASCADE 命令 来 分 析 表 和 索引 的 结构 。 要 注意 的 是 ， 如 果 表 很 大 , 分 
析 过 程 可 能 需要 花费 很 长 的 时 间 ,， 因为 分 析 操作 是 串 行 的 。 如 果 在 生产 环境 下 ， 而 且 业 务 比 较 繁 
忙 ， 那 么 这 个 操作 可 能 无 法 运行 ， 或 者 会 对 业务 产生 很 大 的 影响 ， 这 种 情况 下 ， 就 可 以 使 用 
oerr12700diag 工具 了 。 


SQL> set serveroutput on 
SQL» execute oerrl2700di ag( 2989, 16777219, 4294941081) 


使 用 oerr12700 和 oerr12700diag 工具 进行 存储 时 ,需要 输入 3 个 参数 ,这 些 参数 就 是 ORA-600 
[12700] 后 面 的 3 个 参数 。 

如 果 确 定 是 索引 损坏 , 一 般 来 说 可 以 直接 重建 索引 ; 而 如 果 是 数据 块 损坏 ， 就 需要 进行 数据 
块 修复 ， 如 果 无 法 修复 ， 可 以 跳 过 坏 块 导 出 数据 ， 然 后 重建 数据 库 对 象 。 

如 果 在 索引 和 表 中 均 未 发 现 问题 , 那么 情况 就 比较 复杂 了 , 可 能 是 出 现 了 某 个 和 一 致 性 读 有 
关 的 Bug. 如 果 这 个 问题 是 可 重 现 的 , 那么 通过 EVENT 10226 就 可 以 进行 更 深入 的 分 析 。EVENT 
10226 的 含义 是 EVENT: 10226 "trace CR applications of undo for data operations"， 可 以 输出 大 量 
UNDO 和 REDO 的 信息 ， 协 助 分 析 可 能 存在 的 问题 。 

SQL»alter session set events '10226 trace name context forever, level 10' ; 

SQL» 执行 出 问题 的 模块 

上 面 介绍 了 分 析 ORA-600 [12700] 问 题 分 析 的 大 体 思路 ， 下 面 通 过 老 白 和 网 友 “ 风 ”的 一 段 
QQ 对话 ， 来 介绍 一 个 真实 的 问题 分 析 案 例 。 

风 12:17:43 

老 白 ， 我 碰 到 了 一 个 奇怪 的 问题 ， 你 帮 载 分 析 一 下 : 


SQL» drop index pk w avg; 
drop index pk w avg 
* 


ERROR at line 1: 

ORA- 02429: cannot drop index used for enforcement of unique/pri mary key 
SQL» alter table w avg drop primary key; 

alter table w avg drop primary key 

党 
ERROR at line 1: 

ORA-00600: internal error code, arguments: [12700], [25], [4228580], [178], [], 
[], [b Í 
жок Wi 2000 ， 数 据 库 是 0racle 8.1.6, 


老 网 虫 白 鳝 12:19:12 
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JI ANALYZE TABLE ... VALIDATE STRUCTURE 语 揣 分 析 一 下 表 的 结构 。 
风 12:21:21 

我 已 经 分 析 过 了 ， 没 有 发 现 错误 。 

老 网 虫 白 鳝 12:22:34 


你 做 一 个 10 级 的 10046 TRACE ， 然 后 执行 这 个 语句 ， 查 看 报错 信息 。 从 0RA- 600 [12700] 错误 的 参数 来 看 ， 
应 该 是 25 号 对 象 存在 问题 ， 注 意 ， 应 该 是 DATA0B] #=25 ,而 不 是 0Bj # 。 


JR 12:22:58 
DATAOBJ #25 对 应 的 表 是 Sys. соп$, 
老 网 虫 白 鳝 12:23:12 


如 果 是 表 5Y5. CON$ ， 那 就 对 了 ， 这 就 能 解释 为 什么 删除 主键 时 会 报错 了 ， 看 样子 不 是 数据 表 的 问题 ， 而 是 5C0N$ 
的 问题 。 要 删除 主键 ， 必 须要 操作 C0N$ 这 张 表 。 

接 下 来 ， 你 做 一 个 10046 TRACE ， 就 可 以 看 到 相关 的 参数 了 。 

直接 执行 这 个 语句 是 不 是 也 报错 ? 


JR 12:26:34 


对 ， 出 错 了 

ora-600 12700 

select * from con$ where пате=' PK М AVG' 正常 。 

select * from con$ where пате= РК М AVG' and owner#=49 就 出 错 了 。 


老 网 虫 白 鳝 12:30:34 

CONS 表 有 问题 ， 你 加 上 FULL 提示 看 看 ， 应 该 就 不 会 报错 了 ， 两 个 SQL 条 件 不 同 ， 走 的 执行 计划 也 不 同 ， 可 能 一 
个 走 了 索引 一 个 没 走 。 全 表 扫 描 的 就 没有 报错 。 

风 12:33:19 

Жж FULL 提示 ， 是 可 以 执行 的 ， 没 有 报错 。 

老 网 虫 白 鳝 12:34:10 

看 样子 是 索引 坏 了 。 先 验证 一 下 索引 吧 , 

风 12:41:12 


SQL» ANALYZE index | CONI VALIDATE STRUCTURE; 索引 已 分 析 

SQL» ANALYZE index | CON2 VALIDATE STRUCTURE; 索引 已 分 析 

SQL» alter table w avg drop primary key; 

alter table w avg drop primary key 

* 

ERROR at line 1: 

ORA-00600: internal error code, arguments: [12700], [25], [4228580], [178], [], 
П.И, [] 

删除 主键 时 是 换 了 一 个 用 户 的 ， 前 面 是 用 9Y9 执行 的 。 但 换 了 用 户 还 是 一 样 报错 。 


老 网 虫 白 鳝 12:43:46 


183% OWNER to E NAME 的 条 件 访问 CON$ 使 用 的 索引 是 1 _CON1 ,我 发 一 个 0err12700., 501 给 你 ,这 里 有 两 个 
存储 过 程 ， 执 行 一 下 ， 看 看 结果 。 
这 是 一 个 分 析 脚 本 ,要 用 SYS 账号 创建 存储 过 程 。 


17.1 ORA-600 [12700] 错 误 的 分 析 过 程 391 


风 12:51:46 


SQL» execute oerr12700(25,4228580, 178) 

ORA-600 [12700] [25],[4228580],[178] 

there is an index pointing to a row in SYS. CONS 

row is slot 178 in file 1 block 34276 

one index entry is pointing to ROW Dz' AAAAAZAABAAAI XkACy 
You may want to check the integrity of SYS. CONS 
executing : 

dbv file=C:\ ORACLE\ ORADATA\ GDLS2003| SYSTEMOT. DBF 
blocksizez8192 start =34276 

end=34276 

IF дару does not show any corruption, you can try to 
find the corrupted indexes using the queries proposed 
by the procedure oerrl2700di ag( 25, 4228580, 178) 


PL/SQL procedure successfully completed 
Kl 12:52:16 
SQL> execute oerrl2700di ag( 25, 4228580, 178) 


F dbv did not show any corruption, you can try to 

ind the corrupted indexes using following queries 

f a query returns "no rows selected" index is sane 

f a query returns AAAAAZAABAAAI XkACy index is corrupted 


To test SYS.CON$ indexes 


To test INDEX I| CONI you run 


select rowid "I CONI corrupted!" 
rom 
SELECT /*+ INDEX FFS(CON$,I CONI) */ 

OWNER#, rowid from SYS. CON$ where OWNER#=OWNER# 
where rowi dz' AAAAAZAABAAAI XkACy' 


To test INDEX I| CON2 you run 


select rowid "I СОМ corrupted!" 

from 

(SELECT /** INDEX FFS(CON$,I CON2) */ 
CON#, rowid from SYS. CONS where CON#=CON# 
where rowi dz' AAAAAZAABAAAI XkACy' 


PL/SQL procedure successfully completed 
老 网 虫 白 鳝 12:53:06 
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select rowid "|_CON1 corrupted! "from 
(SELECT /*+ INDEX FFS(CON$,I CONI) */ 

OWNER#, rowid from SYS. CONS 

where OWNER#=OWNER#) where rowid=' AAAAAZAABAAAI XkACy' ; 
执行 一 下 上 面 的 那个 查询 语句 ， 看 看 是 什么 结果 。 


风 12:53:53 

SQL» select rowid "|_CON1 corrupted!" 

2 from 

3 (SELECT /*+ I NDEX FFS(CON$, I CONI) */ 

4 OWNER£Z,rowid from SYS. CONS where OWNERZZOWNER£) 

5 where гомі dz' AAAAAZAABAAAI XkACy' ; 

| CONI corrupted!--------------+---- AAAAAZAABAAAI ХКАСу 
老 网 虫 白 鳝 12:54:47 


可 以 用 DBM95_ROWI D 包 的 汶 数 查看 块 号 、 文 件 号 和 序号 ,这 样 就 找到 索引 损坏 的 位 置 了 ， 然 后 可 以 使 用 BBED т 
具 去 修改 。 

| CONI 是 一 个 B00TSTRAP$ 对象 ， 不 能 重建 ， 只 能 通过 BBED 工具 修改 。 如 果 是 普通 的 索引 就 好 办 了 ， 直 接 重 
建 即 可 。 


风 12:56:17 

对 ， 不 能 重建 ， 也 不 能 删除 。 

网 虫 白 鳝 12:56:54 

我 以 前 碰 到 过 类 似 的 问题 ， 出 现 0RA- 8102 错误 ， 后 来 也 是 用 BBED 工具 修改 解决 的 。 
风 12:59:34 

DATA_OB] ЕСТ 10# RFILE# BLOCK# ROW# 


25 1 34216 178 
这 个 是 那个 ROWI D 的 内 容 。 


老 网 虫 白 鳝 13:02:57 
把 1134276 块 转 储 出 来 。 
风 13:18:28 


已 经 转 储 出 来 了 
如 何 判断 是 否 跟前 面 的 ROWI D 一 样 ? 


老 网 虫 白 鳝 13:21:26 
用 FULL 提示 取出 ROWI D, AAAAAZAABAAAI XkABd ， 和 刚才 的 不 一 样 吧 ? 


ex 


风 13:26:23 

不 一 样 ， 前 面 是 AAAAAZAABAAAI XKACy , 

DATA OBJECT IDs RFILE# BLOCK# ROW# 
— x 1 мш 1% 
老 网 虫 白 鳝 13:27:04 


从 块 转 储 中 可 以 看 到 ，R0OWID 对 应 的 记录 是 0X176:pri[178] sfll=-1, 
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这 表示 该 记录 不 存在 ，5f1| 应 该 指向 一 个 字 节 偏 移 量 ， 如 果 是 " 一 1" 就 说 明 这 条 记录 可 能 已 经 删除 了 。 
JU 13:27:44 

哦 ， 就 是 少 了 这 行 ， 那 如 何 去 操 作 呢 ? 

老 网 虫 白 鳝 13:28:11 


要 将 索引 中 的 ROWI D 修改 为 真实 的 ROWI D ,只 能 使 用 BBED 工具 。 首 先 通过 索引 找到 那 条 记录 ,然后 通过 select 
[*+ full(a) * rowid,... From con$ a Where ownerz... And пате =. ... 120) 354] КОМО, Ж 
用 DBM9_ROWID 包 解 析出 FILE#、BLOCK# 和 ROW#， 重 新 组 合 为 索引 项 中 的 ROW D, 最 后 用 BBED 工具 将 索引 
项 修改 为 这 个 值 ， 就 可 以 了 。 

不 过 修改 前 一 定 要 备份 数据 文件 ， 一 旦 出 现 问题 还 可 以 恢复 。 


老 网 虫 白 鳝 13:36:52 
这 个 操作 对 你 来 说 可 能 有 点 难度 ， 要 了 解数 据 块 的 结构 才能 做 到 。 最 简单 的 方法 还 是 导出 数据 ， 然 后 重建 数据 库 。 
风 13:40:37 


想 试验 一 下 ， 但 是 不 知道 怎么 操作 。 

唉 ,刚才 和 应 用 那 边 沟通 过 了 ， 没 时 间 了 。 只 能 导出 数据 重建 数据 库 了 。 

呵呵 ， 非 常 感谢 老 白 。 

由 于 “ 风 ” 对 手工 修改 数据 字典 并 无 把 握 ， 因 此 这 个 问题 并 没有 深入 讨论 下 去 , 后 来 老 日 通 
过 一 个 实验 重 现 了 这 个 故障 ， 并 记录 了 故障 处 理 的 全 部 过 程 。 

SQL» drop index idx t1; 

drop index idx t1 

* 


ERROR at line 1: 
ORA-00600: internal error code, arguments: [ktssdrpl], [4], [4], [130707], [], 
[], TT [I 


ft ALERT LOG 日 志 中 ， 可 以 找到 如 下 信息 : 


Mon Feb 13 11:03:50 2012 

Errors in file /opt/oracle/admin/orcl/udump/orcl ora 26205.trc: 

ORA-00600: internal error code, arguments: [ktssdrpl], [4], [4], [130707], 11, 11, 11, 
[] 


打开 orcl. ora, 26205.trc 文件 ， 可 以 看 到 : 


*** 2012-02-13 11:03:50.714 

ksedmp: internal or fatal error 

ORA-00600: internal error code, arguments: [ktssdrp1], [4], [4], [130707], 11, 11, 11, 
[] 

Current SQL statement for this session: 

drop index idx t1 

E Call Stack Trace ----- 


calling call entry argument values in hex 

location type point (? means dubious value) 

ksedst() +27 cal | ksedst1() 071? 

ksedmp() +557 call ksedst() 0? 070? 0? 67A035F0 ? 
0? 

ksfdmp() +19 call ksedmp() 3 ? BFFFB2F8 ? ADC338D ? 
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CE67960 ? 3 ? CE15B3C ? 


kgerinv() +177 ca 00000000 CE67960 ? 3 ? 

kgeasnmierr() +40 Ca kgerinv() CE67960 ? CED2C28 ? C393C24 ? 
3 ? BFFFB330 ? 

ktssdrp segment()41 ca kgeasnmierr() CE67960 ? CED2C28 ? C393C24 ? 

749 370? 4? 

di xdrv() +2540 ca ktssdrp segment() BFFFB578 ? 0 ? B727E7C0 ? 
41 ? 1 ? BFFFB598 ? 

opiexe() +11140 ca di xdr v() A? B727FBBC ? O ? C? 
ADA884D ? B727FBBC ? 

0piosq0() +2701 ca opi exe() 410? BFFFCIBO ? 

kpooprx() *215 ca opiosq0() 3 7 E? BFFFC2AC ? A4 ? 

kpoal 8() +673 ca kpooprx() BFFFED94 ? BFFFD024 ? 11? 
1? 0? A4? 

opiodr() +976 Ca 00000000 5E ? 17 ? BFFFED90 ? 

ttcpi p( ) +1085 Ca 00000000 5E ? 17 ? BFFFED90 ? 0 ? 

opitsk()+1054 ca ttcpip() CE6F180 ? 5E ? BFFFED90 ? 0 ? 
BFFFEA70 ? BFFFEEAO ? 

opiino() +821 ca opitsk() 0? 0? 

opiodr() +976 ca 00000000 3С? 4 ? BFFFF960 ? 

opi drv() +466 ca opi odr() 3С? 4? BFFFF960 ? 0 ? 

sou20() +91 ca opi drv() 3C ? 4 ? BFFFF960 ? 

opi mai real() +117 Ca sou20() BFFFF944 ? 3C ? 4 ? 
BFFFF960 ? 

mai n() +111 Ca орі таі геа! () 2 7 BFFFF990 ? 

Ерс start main() са 00000000 2 7 BFFFFA54 ? BFFFFA60 ? 

+211 925056 ? A5AFF4 ? 0 ? 

we ee Binary Stack Dump --------------------- 


在 trace 文件 中 并 没有 看 到 当前 执行 的 SQL， 所 以 需要 进行 一 次 10046 TRACE, ， 这 里 只 需 分 
析 问 题 是 出 现在 哪 条 SQL 上 的 ， 因 此 不 需要 很 高 级 别 的 跟踪 ， 一 般 的 SQL_TRACE 就 能 满足 要 
求 了 。 

SQL» conn /as sysdba 


Connected. 
SQL» alter session set sql_trace=true 


Session altered 


SQL» drop index scott.idx t1; 
drop index scott.idx t1 
* 
ERROR at line 1: 
ORA-00600: internal error code, arguments: [ktssdrpl], [4], [4], [130707], [], 
||. & t 


trace 文件 已 经 产生 了 ， 下 一 步 要 打开 trace 文件 来 检查 到 底 在 哪 条 SQL 上 出 现 了 问题 : 


STAT #6 10=1 cnt=0 pid=0 pos=1 obj =14 op='TABLE ACCESS CLUSTER SEG$ (cr=3 pr=0 pw=0 
time=56 us)' 

STAT #6 id=2 cnt=1 pid=1 pos=1 obj =9 op='INDEX UNI QUE SCAN |_FILE# BLOCK# (cr=2 pr=0 
pw=0 time=31 us)' 

*** 2012-02-13 11:24:50. 213 
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ksedmp: internal or fatal error 
ORA-00600: internal error code, arguments: [ktssdrp1], [4], [4], [130707], [], 11, 11, 


[] 
Current SQL statement for this session: 
drop index scott.idx t1 


我 们 可 以 看 到 ， 在 访问 SEG$ 的 时 出 现 了 问题 ， 这 种 情况 很 可 能 是 数据 字典 不 一 致 引起 的 。 
и a 不 一 致 带 来 的 问题 。 由 于 这 个 系统 
没有 安装 过 hcheck， 我 们 首先 要 安装 hcheck TH, HAT hcheck 的 版 本 有 2.0 和 3.5 两 个 ，3.5 版 
本 适用 于 9i 及 更 新 的 版 本 ，2.0 版 本 适用 于 8i 及 更 早 的 版 本 。 要 使 用 hcheck 工具 必须 先 安装 
hout.sql ( 参见 Metalink 101468.1 ): 


[oracle@j ustdb ~]$ sqlplus '/as sysdba 

SQL*Plus: Release 10.2.0.4.0 - Production on Mon Feb 13 14:57:22 2012 
Copyright (c) 1982, 2007, Oracle. All Rights Reserved 

Connected to: 

Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production 


With the Partitioning, Oracle Label Security, OLAP, Data Mining 
and Real Application Testing options 


SQL» @hout 

Package created. 

No errors. 

Package body created 
SQL> @hcheck3. sql 
Package created. 
Package body created. 


Н. Check Version 9i+/hc3. 35 


Catalog Fixed 
Procedure Name Version Vs Release Run 
SynLastDDLTi m ... 1002000400 » 1001000200 : n/a 
LobNot!nObj ... 1002000400 » 1000000200 : n/a 
Mi ssi ngOI DOnObj Col ... 1002000400 <= *AII Rel* : Ok 
SourceNot! nObj ... 1002000400 > 1002000100 : n/a 
I ndi ndpar Mismatch ... 1002000400 <= 1102000100 : Ok 
I nvCorrAudit ... 1002000400 <= 1102000100 : Ok 
OversizedFiles ... 1002000400 <= *AII Rel* : Ok 
TinyFiles ... 1002000400 > 900010000 : n/a 
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PoorDefaultStorage 1002000400 <= *A Rel * Ok 
PoorStorage 1002000400 <= *A Rel * Ok 

issTabSubPart 1002000400 > 900010000 п/а 
PartSubPartMismatch 1002000400 <= 1102000100 Ok 
TabPartCountMi smatch 1002000400 <= *А Rel * Ok 
OrphanedTabComPart 1002000400 > 900010000 п/а 
ZeroTabSubPart 1002000400 » 3902000100 п/а 

issingSum$ 1002000400 <= *А Rel * Ok 

issingDir$ 1002000400 <= *А Rel * Ok 
рир i cateDataobj 1002000400 <= *А Rel * Ok 
Obj SynMi ssi ng 1002000400 <= *A Rel * Ok 
Obj SegMi ssi ng 1002000400 <= *А Rel * Ok 
Or phanedUndo 1002000400 <= *А Rel * Ok 
Or phanedl ndex 1002000400 <= *А Rel * Ok 

HCKE-0016: Orphaned IND$ (no SEG$) 

ORPHAN 1 ND$: OB) 264917 DOB) =64917 TS=4 RFILE/BLOCK=4 130707 BO#=64916 SegType= 
OrphanedlndexPartition 1002000400 <= *А Rel * Ok 
OrphanedindexSubPartition 1002000400 <= *А Rel * Ok 
OrphanedTable 1002000400 <= *А Rel * Ok 
OrphanedTablePartition 1002000400 <= *A Rel * Ok 
OrphanedTableSubPartition 1002000400 <= *А Rel * Ok 

issingPartCol 1002000400 <= *А Rel* : Ok 
OrphanedSeg$ 1002000400 <= *А Rel* : Ok 
OrphanedI ndPart Obj # 1002000400 <= 1101000600 : Ok 
DuplicateBlockUse 1002000400 <= *А Rel* : Ok 
Hi ghObj есі ds 1002000400 > 801060000 : n/a 
PQsequence 1002000400 > 800060000 : n/a 
TruncatedCl uster 1002000400 > 801070000 : n/a 
FetUet 1002000400 <= *A Rel* : Ok 
Uet OCheck 1002000400 <= *А Rel* : Ok 
ExtentlessSeg 1002000400 <= *А Rel* : Ok 
Segl essUET 1002000400 <= *А Rel * Ok 
Badlnd$ 1002000400 <= *AII Rel* Ok 
BadTab$ 1002000400 <= *AII Rel* : Ok 
Badl col DepCnt 1002000400 <= 1101000700 : Ok 
War nl col Dep 1002000400 <= 1101000700 : Ok 
Onli neRebui | d$ 1002000400 <= *A Rel* : Ok 
DropForceType 1002000400 > 1001000200 : n/a 
TrgAfterUpgrade 1002000400 <= *А Rel* : Ok 
FailedinitJVMRun 1002000400 <= *А Rel* : Ok 
TypeReusedAfterDrop 1002000400 > 900010000 : n/a 
dgenl$TTS 1002000400 > 900010000 : n/a 
DroppedFuncl dx 1002000400 > 902000100 : n/a 
BadOwner 1002000400 > 900010000 : n/a 
UpgCheckc0801070 1002000400 <= *AII Rel* : Ok 
BadPublicObjects 1002000400 <= *А Rel* : Ok 
BadSegFreelist 1002000400 <= *А Rel* : Ok 
BadCol # 1002000400 > 1001000200 : n/a 
BadDepends 1002000400 <= *А Rel* : Ok 
Check Dual 1002000400 <= *AII Rel* Ok 
Obj ect Names 1002000400 <= *А Rel * Ok 
BadCboHi Lo 1002000400 <= *AII Rel* Ok 
ChklotTs 1002000400 <= *А Rel * Ok 
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0Segmentindex ... 1002000400 <= *AII| Rel* : Ok 
BadNext Obj ect ... 1002000400 <= *AII Rel* : Ok 
Orphani ndopt ... 1002000400 » 902000800 : n/a 
UpgFl gBi tT mp ... 1002000400 » 1001000100 : n/a 
RenCharVi ew ... 1002000400 » 1001000100 : n/a 
Upg9i Tab$ ... 1002000400 > 902000400 : n/a 
Upg9i TsI nd ... 1002000400 > 902000500 : n/a 
Upgl0glnd$ ... 1002000400 » 1002000000 : n/a 
DroppedROTS ... 1002000400 <= *AII Rel* : Ok 
ChrLenSmtcs ... 1002000400 <= 1101000600 : Ok 
FilBlkZero ... 1002000400 <= *AII Rel* : Ok 


Found 1 potential problem(s) and 0 warning(s 
Contact Oracle Support with the output 
to check if the above needs attention or not 


PL/SQL procedure successfully completed 
SQL» 
我 们 可 以 看 到 ， 在 本 次 扫描 中 出 现 了 一 个 错误 : 


HCKE-0016: Orphaned IND$ (no SEG$) 
ORPHAN IND$: OB) 264917 DOB) =64917 TS=4 RFILE/BLOCK=4 130707 BO#=64916 SegType= 


这 个 错误 说 明 IND$ 中 的 对 象 没有 SEG$ 信 息 ，OBJECT ID 是 64917， 我 们 可 以 验证 一 下 : 


SQL» col object name format a30 trunc 
SQL» set line 132 
SQL» select owner,object name from dba objects where object idz64917; 


OWNER OBJ ECT. NAME 


确实 是 要 删除 的 这 个 索引 。 从 几 方 面 的 分 析 来 看 ， 都 定位 到 了 这 个 索引 ， 因 此 下 一 步 我 们 就 
需要 修复 这 个 问题 ， 在 SEG$ 中 手工 输入 相关 的 数据 。 由 于 修改 字典 数据 是 十 分 危险 的 操作 ， 
此 建议 操作 之 前 对 数据 库 进行 备份 。 另外, 进行 该 操作 时 最 好 停 掉 业 务 系统 , 在 维护 模式 下 操作 。 

首先 关闭 数据 库 ， 然 后 重新 以 限制 模式 启动 数据 库 : 

9QL> Shutdown immediate 

Database closed. 

Database dismounted 

ORACLE Instance shut down 


SQL> startup restrict; 
ORACLE Instance started 


Total System Global Area 1241513984 bytes 


Fixed Size 1267212 bytes 
Variable Size 436210164 bytes 
Database Buffers 188529152 bytes 
Redo Buffers 15507456 bytes 


Database mounted. 
Database opened. 
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SQL» alter system set "_smu_debug_mode"=1 scope=memory 

System altered. 

SQL» set transaction use rollback segment system 

Transaction set 

SQL» select user id,username from dba users where username=' SCOTT' 
USER I D USERNAME 


51 SCOTT 


SQL» select count(*) from dba extents where segment name= |DX_T1 and owner =' SCOTT' 


COUNT ( *) 
а 
在 正式 插入 数据 前 ， 还 需要 知道 这 张 表 的 USER# 信 息 ， 以 及 扩展 数量 信息 ， 有 了 这 些 信息 ， 


就 可 以 执行 下 面 的 INSERT 语句， 手工 修改 SEGS: 


SQL» insert into seg$ 


2 [ 
3 files, block#, types, ts#, blocks, extents 
4 iniexts, minexts, maxexts,extsize, extpct, user# 


bitmapranges, cachehint, scanhint, hwmincr 
) 
values 

[ 


5 6 1 8 9 10 8, 1, 2147483645, 128 0, 57, 


1 row created. 
SQL> commit; 


Commit complete. 
完成 操作 后 ， 可 以 重启 数据 库 ， 然 后 再 次 删除 索引 : 


SQL» drop index idx t1; 
drop index idx t1 
* 


ERROR at line 1: 
ORA-00603: ORACLE server session terminated by fatal error 
大 家 可 能 会 因为 这 个 问题 惊 出 一 身 冷汗 ， 因 为 查看 ALERT LOG 日 志 时 ， 会 发 现 : 


Mon Feb 13 15:56:36 2012 
Errors in file /opt/oracle/admi n/orcl/bdump/orcl_smon_24807.trc: 
ORA-00600: internal error code, arguments: [ktssdro segment1], [4], [16867091], [0] 
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[], [1, I), I] 

Mon Feb 13 15:56:38 2012 

Errors in file /opt/oracle/admin/orcl/bdump/orcl pmon 24794.trc: 
ORA- 00474: SMON process terminated with error 

Mon Feb 13 15:56:38 2012 

PMON: terminating Instance due to error 474 

Instance terminated by PMON, pid = 24794 


由 于 出 现 了 ORA-600 [ktssdro_segment1] 错 误 ， 数 据 库 实例 宕 机 了 。 不 要 害怕 ， 这 是 因为 第 
一 次 删除 索引 时 ,已 经 有 一 部 分 操作 导致 数据 字典 和 数据 文件 出 现 了 不 一 致 , 因此 在 第 二 次 删除 
索引 时 ，SEG$ 的 数据 没有 正常 删除 。 我 们 需要 删除 SEG$ 的 数据 ， 根 据 刚才 插入 SEG$ 的 语法 ， 
编写 一 个 DELETE 命令 ， 必 须 在 数据 库 重 新 启动 后 马上 执行 删除 操作 ， 否 则 数据 库 实 例 还 是 会 
宕 机 。 

[oracle@ustdb ~]$ sqlplus '/as sysdba 


SQL*Plus: Release 10.2.0.4.0 - Production on Mon Feb 13 16:13:05 2012 
Copyright (c) 1982, 2007, Oracle. All Rights Reserved 
Connected to an idle Instance 


SQL» startup restrict; 
ORACLE Instance started 


Total System Global Area 1241513984 bytes 


Fixed Size 1267212 bytes 
Variable Size 436210164 bytes 
Database Buffers 188529152 bytes 
Redo Buffers 15507456 bytes 


Database mounted. 
Database opened. 
SQL» delete from seg$ where file#=4 and block£z130707 and ts#=4 


1 row deleted. 

SQL» commit; 

Commit compl ete. 

SQL» shutdown abort 

ORACLE Instance shut down. 


SQL» startup 
ORACLE Instance started 


Total System Global Area 1241513984 bytes 


Fixed Size 1267212 bytes 
Variable Size 436210164 bytes 
Database Buffers 188529152 bytes 
Redo Buffers 15507456 bytes 


Database mounted. 
Database opened. 
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数据 库 正常 打开 了 ， 而 且 ALERT LOG 日 志 没有 再 次 报错 ， 我 们 用 hcheck 工具 再 ; 


据 字 典 。 


SQL» set serveroutput on size unlimited 
SQL» execute hcheck. full; 
H. Check Version 9i +/hc3. 35 


Catalog Fi xed 

Procedure Name Version Vs Release Run 
SynLastDDLTi m ... 1002000400 » 1001000200 : n/a 
LobNotlnobj ... 1002000400 > 1000000200 : n/a 
1551 п901 DOnObj Col ... 1002000400 <= *A Rel* : Ok 
SourceNot! nObj ... 1002000400 > 1002000100 : n/a 
ndi ndparMi smatch ... 1002000400 <= 1102000100 : Ok 
nvCorrAudit ... 1002000400 <= 1102000100 : Ok 
OversizedFiles ... 1002000400 <= *А Rel* : Ok 
TinyFiles ... 1002000400 > 900010000 : n/a 
PoorDefaultStorage ... 1002000400 <= *A Rel* : Ok 
PoorStorage ... 1002000400 <= *A Rel* : Ok 
issTabSubPart ... 1002000400 > 900010000 : n/a 
PartSubPartMismatch ... 1002000400 <= 1102000100 : Ok 
TabPartCountMi smatch ... 1002000400 <= *A Rel* : Ok 
OrphanedTabComPart ... 1002000400 » 900010000 : n/a 
ZeroTabSubPart ... 1002000400 > 902000100 : n/a 
issingSum$ ... 1002000400 <= *A Rel* : Ok 
issingDir$ ... 1002000400 <= *A Rel * Ok 
DuplicateDataobj ... 1002000400 <= *A Rel * Ok 
Obj SynMi ssi ng ... 1002000400 <= *A Rel * Ok 
Obj SegMi ssi ng ... 1002000400 <= *A Rel * Ok 
OrphanedUndo ... 1002000400 <= *A Rel * Ok 
Or phanedl ndex ... 1002000400 <= *A Rel * Ok 
OrphanedlndexPartition ... 1002000400 <= *A Rel * Ok 
OrphanedindexSubPartition ... 1002000400 <= *A Rel * Ok 
OrphanedTable ... 1002000400 <= *A Rel * Ok 
OrphanedTablePartition ... 1002000400 <= *A Rel * Ok 
OrphanedTableSubPartition ... 1002000400 <= *A Rel * Ok 
issingPartCol ... 1002000400 <= *A Rel* : Ok 
OrphanedSeg$ ... 1002000400 <= *A Rel* : Ok 
OrphanedI ndPart Obj # ... 1002000400 <= 1101000600 : Ok 
DuplicateBlockUse ... 1002000400 <= *A Rel* : Ok 
Hi ghObj есі ds ... 1002000400 > 801060000 : n/a 
PQsequence ... 1002000400 > 800060000 : n/a 
TruncatedCluster ... 1002000400 > 801070000 : n/a 
Fet Uet ... 1002000400 <= *AII Rel* : Ok 
Uet OCheck ... 1002000400 <= *Al| Rel* : Ok 
ExtentlessSeg ... 1002000400 <= *AII Rel* : Ok 
Segl essUET ... 1002000400 <= *AII Rel* : Ok 
Badlnd$ ... 1002000400 <= *AII Rel* : Ok 
BadTab$ ... 1002000400 <= *AII Rel* : Ok 
Badl col DepCnt ... 1002000400 <= 1101000700 : Ok 
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WarnlcolDep ... 1002000400 <= 1101000700 : Ok 
Onl i neRebui l d$ ... 1002000400 <= *AII Rel* : Ok 
DropForceType ... 1002000400 » 1001000200 : n/a 
TrgAfterUpgrade ... 1002000400 <= *AII Rel* : Ok 
FailedinitJVMRun ... 1002000400 <= *AII Rel* : Ok 
TypeReusedAfterDrop ... 1002000400 » 900010000 : n/a 
dgenl$TTS ... 1002000400 > 900010000 : n/a 
DroppedFuncl dx ... 1002000400 > 902000100 : n/a 
BadOwner ... 1002000400 » 900010000 : n/a 
UpgCheckc0801070 ... 1002000400 <= *А Rel* : Ok 
BadPublicObjects ... 1002000400 <= *A Rel* : Ok 
BadSegFreelist ... 1002000400 <= *A Rel* : Ok 
BadCol # ... 1002000400 » 1001000200 : n/a 
BadDepends ... 1002000400 <= *A Rel* : Ok 
CheckDua ... 1002000400 <= *A Rel* : Ok 
Obj ect Names ... 1002000400 <= *A Rel* : Ok 
BadCboHi Lo ... 1002000400 <= *А Rel* : Ok 
ChklotTs ... 1002000400 <= *A Rel* : Ok 
oSegmentindex ... 1002000400 <= *A Rel* : Ok 
BadNext Obj ect ... 1002000400 <= *А Rel* : Ok 
Or phanl ndopt ... 1002000400 > 902000800 : n/a 
UpgFlgBi tT mp ... 1002000400 » 1001000100 : n/a 
RenCharVi ew ... 1002000400 » 1001000100 : n/a 
Upg9i Tab$ ... 1002000400 > 902000400 : n/a 
Upg9i TsI nd ... 1002000400 > 902000500 : n/a 
Upgl0glnd$ ... 1002000400 » 1002000000 : n/a 
DroppedROTS ... 1002000400 <= *AII Rel* : Ok 
ChrLenSmtcs ... 1002000400 <= 1101000600 : Ok 
Fil Bl kZero ... 1002000400 <= *AII Rel* : Ok 


Found 0 potential problem(s) and 0 warning(s 


PL/SQL procedure successfully completed 

可 以 看 到 ，hcheck 工具 没有 发 现 问 题 , BOA, BEBEULHEUR o 不 过 大 
家 可 能 会 认为 上 面 的 处 理 过 程 太 过 惊险 。 实 际 上 ， 对 于 这 个 ORA-600 错误 ， 这 种 处 理 方法 是 肯 
定 可 以 解决 问题 的 ， 不 过 对 于 其 他 的 错误 ， 我 们 并 不 清楚 修改 数据 字典 可 能 会 带 来 怎样 的 影响 ， 
此 在 没有 经 过 严格 测试 或 者 对 数据 字典 并 不 十 分 了 解 的 情况 下 , 不 建议 进行 修改 数据 字典 的 操 
作 。 因 为 一 旦 出 现 问题 ， 可 能 导致 数据 库 出 现 更 大 的 故障 。 
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我 的 一 个 客户 最 近 磁 到 了 点 烦心 的 事情 , 他 在 一 套数 据 库 上 面 做 了 导出 备份 , 想 用 移动 硬盘 
把 备份 的 数据 复制 出 来 ,可 没 想 到 一 连 上 移动 硬盘 ， 整 个 服务 器 就 掉 电 了 。 重新 开机 后 ,数据 库 
倒是 能 够 打开 ,不 过 有 些 应 用 模块 却 出 错 了 ,查看 ALERT LOG 日 志 后 ,发 现存 在 大 量 的 ORA-600 
[kdsgrp1] 错 误 。 

这 种 问题 我 以 前 并 没有 碰 到 过 ， 于 是 就 到 Metalink 上 去 查找 ， 查 询 结 果 如 图 17-1 所 示 。 
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从 查询 到 的 文档 标题 可 以 看 出 ，Causes and Solutions for ora-600 [kdserp1] [ID 1332252.1] 像 是 
能 够 给 我 们 提供 答案 的 文档 。 这 份 文档 的 第 一 部 分 说 明了 该 文档 适用 的 Oracle 版 本 和 环境 。 


Applies to: 
Oracle Server - Enterprise Edition - Version: 10.2.0.4 to 11.2.0.2 - Release: 10.2 to 
11.2 


Information in this document applies to any platform 


上 述 内 容 表 示 该 文档 适用 于 10.2 ~ 11.2 版 本 ， 有 具体 的 版 本 号 是 10.2.0.4 ~ 11.2.0.2， 如 果 这 个 
版 本 范围 和 我 们 出 现 问题 的 系统 的 版 本 相差 较 大 , 那么 文档 内 容 和 我 们 碰 到 的 问题 的 关联 性 也 就 
不 高 。 因 此 这 份 资料 仅仅 能 起 到 参考 作用 ， 我 们 不 能 完全 照搬 其 解决 方法 。 


Purpose 
This document discusses the ora-600 [kdsgrpll error, its possible causes and the work 
around solutions that can be tried. 


这 部 分 内 容 阐明 了 该 文档 的 目的 ， 针 对 本 案例 ， 介 绍 了 这 个 ORA-600 错误 的 产生 原因 以 及 
解决 方法 。 

Last Review Date 

June 22, 2011 


上 述 内 容 是 最 近 被 重新 评审 的 时 间 , 如果 已 经 有 好 多 年 没有 经 过 评审 了 , 那么 这 份 文档 中 信 
息 的 准确 性 和 时 效 性 就 要 大 打折 扣 了 。 


Instructions for the Reader 
A Troubleshooting Guide is provided to assist in debugging a specific issue. When 
possible, diagnostic tools are included in the document to assist in troubleshooting. 


这 部 分 内 容 是 对 读者 的 建议 。 再 往 后 就 是 故障 分 析 的 详细 方法 了 。 


Troubleshooting Details 
The ora- 600 [kdsgrpl] error is thrown when a fetch operation fails to find the expected 
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row. The error is hit in memory and so may be a memory only error or anerror that results 
from corruption on disk 

This error may indicate (but is not restricted to) any of the following conditions: 
? Lost writes 

Parallel DML issues 

Index corruption 

Data block corruption 

Consistent read [CR] issues 

? Buffer cache corruption 

A full list of known issues is given in ORA-600 [kdsgrpl] Note 285586.1 Each bug has 
a short description that indicates the circumstances where it is hit. The bug list can 
ре shortened by selecting your database release to showonly those issues that may affect 
you. 
This issue may be intermittent or it may persist until the underlying disk leve 
corruption is fixed. Intermittent issues are likely to be memory based (however 
intermittent access tothe corruption can be confused with intermittent memory issues). 
Common Work Around Solutions 

f the issue is in memory only we can try to immediately resolve the issue by flushing 
he buffer cache but remember to consider the performance impact on production systems 
alter system flush buffer cache 

f we have an intermittent consistent read issue we can try disabling rowCR which is 
an optimization to reduce consistent-read rollbacks during queries by setting. 
row_cr=FALSE in the initialization files. However, this could lead to performance 
degradation of queries. Please check the ratio of the two statistics "RowCR hits"/"RowCR 
attempts" to determine whether the workaround is to be used 

f this is a result of index corruption then we can drop and rebuild the index. Note 
hat this will require a maintenance window on production systems. 

Root Cause Determination 

owlets look at how we discover the root cause of the problem the first stepin finding 
he root cause of this issue is to inspect the generated trace file. The ora-600 wil 
generate bothatracefileinthetracedirectory andan incident file under the i nci dent 
id within the incident directory 

The top part of the trace file tells us the SQL that was being run when the error was 
hit: 


~ o сә 


- Current SQL Statement for this session (sql_id=9mamr7xn4wg7x) ----- 
This immediately shows us the data objects that were accessed. Searching the trace file 
or the text string 'Plan Table' will locate the SQL execution plan that is dumped within 
his trace file. For a persistent issue this allows us to determine which indexes have 
been accessed and so identify indexes that should be validated to check for block 
corruption: 

SQL» analyze index scott.pk dept validate structure online; 

Index analyzed. 
An other approach we can take is to use the file and block information contained in 
thetrace file. At the top of thetrace file we will find information on the block where 
the corruption was found 

*** SESSION 10: (3202.5644) 2011-03-19 04:12:16.910 

row 07c7c8c7.a continuation at 

files 31 block£ 510151 slot 11 not found 
This information can be used to identify the object details in dba extents 

Select owner, segment name, segment type, partition name,tablespace name 

From dba extents 

Where relative fno = «file id» 

And «blocks» between block id and (block ideblocks-1); 

We can then validate this object, for example a table and all it's indexes 


404 第 173 ORA-600 故障 


Analyze table scott.dept validate structure cascade online; 

Remember that we may be dealing with a permanent corruption that is not locatedin the 
object blocks themselves. Examples of this include: 

? Dictionary corruption issue from transportable tablespace operations: check 
dba tablespaces to see if the tablespace has been plugged in. 

? Lost writes in ASM diskgroup mirrors - most likely to be seen when there is heavy 
lOanddiskresyncactivity. Tocheckthis run dbms diskgroup.checkfileto detect mirror 
discrepancies 

If analyze reports no corruption then check if there are any chained rows on the table 
If these exist then we may have an undetected corruption and the issue should reproduce 
Whenever the SQL is run. Exporting the table will also detect this issue 

If analyze and exporting the table (in the presence of chained rows) both report no 
errors then this should be considered a consistent read issue 

Once you understand the nature of the problem you can review the list of known bugs 
and determine which one matches your condition. If you cannot determine which issue 
is affecting you then open a service request with Oracle Support and upload the RDBMS 
and ASM (if applicable)Instance alert logs for all nodes, any trace and incident files 
generated and a full description of the nature of the problem 


通过 对 上 面 资料 的 分 析 ， 再 对 照 ORA-600 的 trace 文件， 我们 发 现 系 统 的 故障 和 这 份 文档 所 
描述 的 情况 具有 很 大 的 相似 性 。 首 先 我 们 需要 排除 由 于 内 存 故障 导致 的 问题 。 

ALTER SYSTEM FLUSH BUFFER_POOL; 

执行 上 面 的 语句 后 ， 问 题 并 没有 消失 ， 打 开 trace 文件 ， 可 以 看 到 以 下 信息 : 


*** SESSION 10: (886. 204) 2012-04-23 09:53:56.577 
row 0f924e83.15 continuation at 
file# 62 block# 1199747 slot 22 not found 


KKK ECKE EK ECKE CK ECKE X K X K XX XX XXX EEEE EEE EEEE EEE EEEE EEE 


KDSTABN GET: 0 ..... ntab: 1 


CUES [HOt 22 sas nrows: 14 
米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 米 


不 难看 出 ，FILE 62、BLOCK 1199747 的 SLOT 22 存在 问题 ， 通 过 以 下 查询 ， 可 以 找到 相关 
的 对 象 。 


select owner,segment name fromdba extents where file_id=62 and block_id<=1199747 and 
(block_id+blocks) >=1199747 


在 同一 个 trace 文件 中 继续 查找 ， 可 以 找到 相关 SQL 及 执行 计划 : 


Plan Table 
wn eee eee eee eee ee ee ee ee eee eee tee ee eee ee eee eee Ф 
ld Operation Name Rows Ti me 
we eee eee ee eee ee ee ee ee eee eee eee tence eee ee eee eee + 
0 SELECT STATEMENT 
1 COUNT STOPKEY 
2 NESTED LOOPS OUTER 2 00:00:01 
3 VIEW 2 00:00:01 
4 SORT ORDER BY 2 00:00:01 
5 TABLE ACCESS BY INDEX ROW D CHOUJ | ANG 2 00:00:01 
6 INDEX RANGE SCAN | NDEX CHOU)! ANG_ MOBI LENO 3 00:00:01 
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7 | TABLE ACCESS BY INDEX ROWID | ACTDATA STAT 106 | 1 | 00:00:01 
| 8 | INDEX UNIQUE SCAN | PK ACTSTAT BATCHID [1 | 


我 们 发 现 ，CHOUJIANG 表 访 问 使 用 了 INDEX_CHOUJIANG_MOBILIENO 这 个 索引 。 那 么 
下 一 步 要 做 的 就 是 删除 该 索引 ， 然 后 进行 重建 ( 需要 重建 该 索引 ， 而 不 是 ALTER INDEX ... 
REBUILD )。 重 建 索引 后 这 个 错误 就 应 该 消失 了 。 

由 于 晚上 只 有 部 分 业务 在 使 用 , 因此 还 无 法 排除 其 他 索引 也 存在 类 似 的 问题 。 于 是 我 们 找 出 
系统 中 业务 相关 的 所 有 表 ， 通 过 以 下 命令 编写 了 一 个 脚本 ， 对 主要 的 表 和 相关 索引 进行 分 析 。 

ANALYZE TABLE CHOUJIANG VALIDATE STRUCTURE CASCADE ONLINE; 

如 果 分 析 过 程 中 出 现 如 下 所 示 的 ORA-1499 错误 ， 那 么 就 说 明 该 表 的 索引 存在 问题 。 

ERROR at line 1: 


ORA-01499: table/index cross reference failure - see trace file 


如 果 找 到 trace 文件 ， 可 以 看 到 trace 文件 中 存在 如 下 信息 : 


*** ACTION NAME:() 2012-04-23 10:43:03.440 

*** MODULE NAME:(sqlplusQdgser CRM M (TNS V1-V3)) 2012-04-23 10:43:03.440 

*** SERVICE МАМЕ: (SYS$USERS) 2012-04-23 10:43:03.439 

*** SESSION ID:(877.4034) 2012-04-23 10:43:03.439 

row not found in index tsn: 17 rdba: 0x3409dcc4 

env: (scn: 0x0004.9fffeb07 xid: 0x0000.000.00000000 uba: 0x00000000.0000.00 
statement num=0 parent xid: xid: 0x0000.000.00000000 scn: 0x0000.00000000 8sch: scn 
0x0000.00000000 

col 0; len 11; (11): 3133 37 31 32 36 36 33 32 39 34 

col 1; len 6; (6): 04 09 01 55 00 0b 


这 些 信 息 已 经 充分 证 明了 索引 和 表 数 据 存在 不 一 致 , 因此 需要 重建 索引 。 因 为 重建 操作 是 通 
过 当前 索引 加 上 索引 的 增 量 来 进行 的 , 因此 通过 重建 或 者 在 线 重 建 操作 , 都 无 法 彻底 消除 这 种 不 
一 致 现象 ， 必 须 先 删除 索引 再 进行 重建 。 

一 般 来 说 ,这 种 问题 都 是 由 存储 方面 的 故障 导致 的 , 因此 问题 并 不 会 孤立 出 现 ,往往 很 多 索 
引 也 存在 类 似 的 不 一 致 现象 。 而 上 只 有 访问 到 了 不 一 致 的 记录 ,系统 才 会 报错 ， 因 此 需要 分 析 系统 
中 所 有 相关 的 索引 ， 可 以 通过 以 下 脚本 进行 。 

ANALYZE TABLE <table_name> VALIDATE STRUCTURE CASCADE ONLINE; 

如 果 这 张 表 上 存在 主键 ,那么 就 应 该 检查 主键 是 否 存 在 问题 : 


LOCK TABLE «TABLE NAME» IN EXCLUSIVE MODE; 
SELECT COUNT(*) FROM «TABLE NAME»; 
SELECT /*+ FULL(TABI) */ COUNT(*) FROM «TABLE NAME» TAB1 


判断 这 两 个 查询 结果 是 否 一 致 。 如 果 不 一 致 ， 就 说 明 主 键 存在 问题 ， 这 种 情况 处 理 起 来 会 比 
较 麻 烦 ， 需 要 删除 主键 约束 以 及 相关 索引 ， 然 后 重建 主键 和 索引 。 如 果 数 据 中 存在 问题 ， 主 键 相 
关 字 段 的 唯一 性 也 存在 问题 , 那么 就 更 麻烦 了 ,这 时 需要 找到 重复 的 数据 ， 并且 手工 删除 重复 的 
记录 。 
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查找 重复 主键 的 方法 有 两 种 。 

口 在 删除 主键 后 重新 添加 主键 时 ， 使 用 exception into 子 句 ， 这 样 存在 主键 重复 的 记录 的 
ROWID 就 会 被 记录 到 异常 表 (EXCEPTION TABLE ) +. 

口 通过 以 下 语句 来 查找 重复 主键 。 


select < 主键 字段 >, COunt(*) from «table name> group by < 主键 字段 > having count(*)>1 


性 能 问题 分 析 


DBA 经 常会 碰 到 性 能 问题 ,很 多 时 候 都 会 感到 束手无策 ， 因 此 本 章 可 能 是 很 多 DBA 都 想 认 
真 研读 的 。 实 际 上 ,性 能 问题 和 普通 问题 的 分 析 并 无 太 大 的 区 别 。 我 们 在 分 析 时 ， 都 需要 通过 自 
己 掌 握 的 知识 来 逐步 缩小 分 析 范 围 ， 并 采用 一 系列 “组 合 拳 ” 来 解决 问题 。 本 章 选 用 的 案例 都 具 
有 一 定 的 代表 性 , 大 家 在 阅读 时 , 不 仅 要 注意 老 白 是 如 何 处 理 这 些 案例 的 ,更 重要 的 是 要 掌握 分 
析 、 解 决 性 能 问题 的 方法 和 思路 。 


18.1 压力 测试 遇 到 的 问题 

朋友 的 公司 为 了 投标 一 个 项 目 ， 需 要 进行 压力 测试 。 这 是 一 套 银行 的 核心 业务 系统 ,客户 要 
求 综合 交易 压力 测试 能 够 达到 每 秒 600 个 交易 ,并 且 系 统 负载 不 能 超过 95%。 系 统 安装 后 ,他 们 
进行 了 自 测 , 但 无 论 怎样 调整 ， 系统 都 只 能 完成 每 秒 不 到 200 个 交易 ， 而 负载 只 有 20907515, TR 
本 压 不 上 去 。 于 是 我 查看 了 相关 的 AWR 报告 ， 发 现 一 个 十 分 有 趣 的 现象 。 


Cache Sizes (end) 


Buffer Cache: 20,480M Std Block Size: 8K 
Shared Pool Size: 5, 008M Log Buffer: 32, 768K 
Load Profile 
mm Per Second Per Transaction 
Redo size: 1,989,039.62 12,816.67 
Logical reads: 181,739.18 1,171.06 
Block changes: 7,007.77 45.16 
Physical reads: 2,112.79 13.61 
Physical writes: 0.57 0.00 
User calls: 12,191. 86 78.56 
Parses: 8,958.80 51.13 
Hard parses: 49.07 0.32 
Sorts: 210.10 1.36 
Logons: 0.03 0.00 
Executes: 11,725.29 15.55 
Transactions: 155.19 


% Blocks changed per Read: 3.86 Recursive Call %: 4.33 
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Rollback per transaction %: 22.56 Rows per Sort: 139.64 


Instance Efficiency Percentages (Target 100%) 


Buffer Nowait %: 99.96 Redo NoWait 9: 100.00 
Buffer Hit 9« 98.84 |n- memory Sort 9 100.00 
Library Hit %: 107.03 Soft Parse %: 99.45 
Execute to Parse %: 23.59 Latch Hit %: 95.60 
Parse CPU to Parse Elapsd %: 2.89 % Non- Parse CPU: 94.08 
Shared Pool Statistics Begin End 
Memory Usage %: 9.52 9.51 
% SQL with executions>1: 94.13 94.34 
% Memory for SQL wlexec>1: 89.00 92.95 
Top 5 Timed Events 
mmm % Total 
Event Waits Time(s) DB Ti me Wait Class 
atch: library cache 179,862 3,360 35.13 Concurrency 
CPU ti me 1,391 14.79 
atch: cache buffers chains 21, 376 642 6.83 Concurrency 
atch: library cache lock 26,875 561 5.96 Concurrency 
atch: library cache pin 30,675 519 5.52 Concurrency 


可 以 看 出 ， 库 缓存 方面 的 争 用 所 占 的 比重 非常 高 ， 查 看 详细 的 等 待 情况 如 下 : 


Event Waits Timeouts Total Wait Avg wait(ms) Waits 
Time (5) [txn 
atch: library cache 179,862 0 3,360 19 14.81 
atch: cache buffers chains 21, 376 21316 642 30 1.76 
atch: library cache lock 26, 875 0 561 21 2.21 
atch: library cache pin 30,675 0 519 17 2.5/3 
db file sequential read 40,017 0 233 6 3.29 
wait list latch free 4,528 0 127 28 0.37 
ibrary cache pin 4,561 0 125 27 0. 38 
kksfbc child completion 2,260 2,258 109 48 0.19 


库 缓 存 相关 的 等 待 事件 在 20 毫秒 左右 ， 看 来 是 SQL 解析 出 现 了 问题 。 软 解析 所 占 比 例 达到 
99.45% ， 不 过 对 人 硬 解析 方面 的 影响 并 不 是 很 大 。 接 下 来 ， 需 要 分 析 相 关 的 时 间 模 型 。 


Statistic Name Ti me(seconds) WTotal DB Ti me 
DB time 9,404.41 100.00 
sql execute elapsed ti me 3,947.37 41.97 
parse time elapsed 2,818.27 29.97 
DB CPU 1,391.36 14.79 
hard parse elapsed time 23.87 0.25 
background elapsed ti me 15.84 0.17 
failed parse elapsed time 12.48 0.13 
background cpu ti me 5.09 0.05 
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PL/SQL execution elapsed time 2.85 0.03 
sequence load elapsed time 0.45 0.00 
hard parse (bind mismatch) elapsed time 0.03 0.00 
hard parse (sharing criteria) elapsed time 0.03 0.00 
inbound PL/SQL rpc elapsed ti me 0.00 0.00 
Java execution elapsed ti me 0.00 0.00 
failed parse (out of shared memory) elapsed t 0.00 0.00 
connection management call elapsed ti me 0.00 0.00 
PL/SQL compilation elapsed ti me 0.00 0.00 
不 难看 出 ， 解 析 的 时 间 占 比 是 29.9% ， 而 硬 解 析 所 占 比例 很 小 ， 只 有 0.25%。 这 种 情况 下 ， 


我 认为 优化 软 解析 会 取得 比较 好 的 效果 。 另 外 ， 由 于 每 秒 存 在 2110 多 个 物理 读 操作 ， 因 此 减少 

物理 读 操 作 也 会 对 整体 性 能 优化 有 较 大 的 帮助 。 鉴 于 以 上 原因 ， 我 提出 了 如 下 优化 建议 : 

О 将 SESSION_CACHED_CURSORS 参数 设置 为 200; 

口 将 OPEN_CURSORS 参数 加 大 为 3000; 

а 如 果 物 理 内 存 充足 ， 可 将 DB Cache 加 大 至 5 ~ 10 GB. 

也 们 根据 上 述 建议 调整 了 整个 测试 环境 , 修改 了 相应 参数 。 第 二 天 , 我 接 到 现场 负责 人 的 电 

W, 进行 调 整 后 每 秒 交 易 数 达到 了 400 左右 ,但 系统 负载 仍然 只 有 30% 左 右 。 不 过 这 与 客户 每 秒 

600 个 交易 的 要 求 仍 差 之 甚 远 。 他 们 希望 我 能 够 到 现场 进一步 对 系统 进行 调整 。 

我 马上 预订 了 机 票 ， 第 二 天 下 午 就 赶 到 了 现场 。 在 查看 了 测试 期 间 采 集 的 AWR 报告 后 ， 我 
发 现 加 大 DB Cache， 设 置 SESSION_CACHED_CURSORS 参数 后 ， 库 缓存 方面 的 争 用 大 幅 减少 
了 ， 只 在 TOP 5 EVENTS 的 最 后 出 现 了 一 个 库 缓存 的 等 待 事件 ， 占 总 等 待 的 2.3%。 不 过 一 些 新 
的 问题 也 随 之 出 现 了 : 

B LOG FILE SYNC 等 待 排 到 了 第 二 位 ， 占 总 等 待 的 19%; 

口 REDO LOG 日 志 每 秒 的 生成 量 达 到 了 2 MB 多 ， 按 照 这 样 计算 ， 每 分 钟 产 生 的 REDO 文 
件 将 超过 120 MB, ， 而 目前 每 个 REDO LOG 文件 的 大 小 仅 为 100 MB, ， 也 就 是 说 ， 不 到 1 
分 钟 就 会 产生 1 次 日 志 切 换 ; 

口 在 几 张 表 上 出 现 了 严重 的 ITL 争 用 ; 

а 系统 使 用 了 较为 陈旧 的 XP128 作为 存储 ,其 性 能 较 差 , 而 且 所 有 的 盘 都 是 RAID 5 的 , 写 
性 能 非常 差 。 

经 过 上 述 分 析 ， 我 决定 采取 如 代码 清单 18-1 所 示 的 几 项 措施 。 


代码 清单 18-1 


-设置 参数 ,解决 几 个 5QL 执行 计划 错误 的 问题 
alter session set " always anti join" =hash; 


--- -设置 一 个 4 GB 的 KEEP POOL, 
ALTER SYSTEM SET DB CACHE KEEP SI 2Е=40 


---- 加 大 LOG BUFFER 460 M 
ALTER SYSTEM SET LOG BUFFER=62914560 


---- 调整 REDO LOG x fF, REDO LOG 文件 加 大 为 2GB 
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ALTER DATABASE DROP LOGFILE GROUP 1; 
ALTER DATABASE ADD LOGFILE THREAD 1 
GROUP 1 ('/dev/vg data04/rlv datal81') SIZE 2147483648; 
--- -将 日 志 切 到 GROUP 1 
ALTER DATABASE DROP LOGFILE GROUP 2; 
LTER DATABASE DROP LOGFILE GROUP 3; 
ALTER DATABASE ADD LOGFILE THREAD 1 
GROUP 2 ('/dev/vg data04/rlv datal82') SIZE 2147483648, 
GROUP 3 ('/dev/vg data04/rlv datal83') SIZE 2147483648; 
ALTER DATABASE ADD LOGFILE THREAD 1 
GROUP 4 ('/dev/vg data04/rlv datal84') SIZE 2147483648, 
GROUP 5 ('/dev/vg data04/rlv datal85') SIZE 2147483648, 
GROUP 6 ('/dev/vg data04/rlv datal86') SIZE 2147483648, 
GROUP 7 ('/dev/vg data04/rlv datal87') SIZE 2147483648; 


=> 


t -生成 脚本 ， 将 P* 的 表 所 相关 的 索引 全 部 放 入 KEEP POOL 
select ‘alter index '||index_name||' storage(buffer pool keep);' from user indexes 
where table name like 'P% 


-生成 脚本 ， 将 P* 的 表 放 入 KEEP POOL 
select 'alter table '||table name||' storage(buffer pool keep);' from user tables 
where table name like 'P% 


- -生成 脚本 ,将 P* 的 表 全 部 扫描 一 遍 ， 使 之 在 测试 前 全 部 放 入 KEEP 池 
select ‘select /** full(a) * * from'||table пате ||' a;' from user tables where 
table name like 'P9'; 


- 加 大 几 张 表 的 1TL 


alter table aknmx pctfree 0 initrans 60; 
alter table aknto pctfree O initrans 60; 
alter table bjyrz pctfree 0 initrans 60; 
alter table bdpal pctfree O initrans 60; 
alter table adkmx pctfree 0 initrans 60; 


调整 后 , 我 们 马上 进行 了 测试 , 发 现 性 能 有 了 明显 的 提升 , 平均 每 秒 交 易 数 提高 到 920 左右 。 
这 时 ， 在 AWR 报告 中 ，LOG FILE SYNC 等 待 排 到 了 第 一 位 ， 虽 然 每 次 等 待 只 有 4 毫秒 ， 但 无 
法 继续 增 大 压力 测试 ， 而 此 时 CPU 的 使 用 率 只 有 不 到 80%。 前 几 天 ， 男 外 一 个 厂家 的 系统 也 在 
此 环境 下 进行 过 测试 , 每 秒 交 易 数 达 到 了 1100, 但 是 CPU 使 用 率 只 有 20%。 客户 对 此 表示 怀疑 ， 
尽管 交易 数 很 高 ， 而 且 事 后 审核 也 并 未 发 现 问题 , 但 在 这 么 大 的 交易 量 下 , 系统 资源 消耗 却 如 此 
之 小 ， 这 确实 不 大 可 信 。 

虽然 我 们 都 认为 竞争 对 手 存在 作 浆 行为 , 但 是 并 没有 确 辫 的 证 据 。 但 如 果 我 们 的 测试 数据 
够 超过 对 手 , 并 且 从 测试 结果 中 能 够 看 到 系统 资源 已 经 完全 耗 尽 , 那么 既 可 以 证 明 系 统 的 吞吐 
力 强 于 对 手 ， 又 可 以 证 明 对 手 存在 舞 次 行为 。 

从 目前 的 情况 来 看 ， 要 想 达 到 此 目标 ,需要 进一步 加 大 DB Cache， 因 此 必须 减少 物理 读 操 
作 的 数量 ,但 这 还 不 足以 使 整个 测试 性 能 有 质 的 飞跃 ,解决 LOG FILE SYNC 等 待 的 问题 才 是 关 
键 。 但 从 目前 存储 的 性 能 来 看 ， 要 想 改 善 REDO LOG 的 写 性 能 几乎 是 不 可 能 的 ，LOG BUFFER 
已 经 加 大 到 了 60 MB ， 再 继续 增加 也 不 会 有 太 大 的 帮助 。 如 何 才能 缩短 LOG FILE SYNC 等 待 的 


=b =b 
or on 
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时 间 呢 ? 

突然 , 我 想起 了 异步 提交 ,这 种 提交 模式 无 需 等 待 LGWR 进程 将 LOG BUFFER 中 的 数据 写 
A REDO LOG 文 件 , 可 以 直接 返回 提交 成 功 。 如 果 在 生产 系统 中 采用 这 种 模式 ， 一旦 实例 宕 掉 ， 
可 能 导致 部 分 已 经 提交 的 事务 丢失 。 但 在 测试 环境 中 ， 并 不 存在 这 个 问题 ,实例 宕 掉 的 情况 极 少 
出 现 。 即 便 出 现 了 这 种 情况 ,也 可 以 重新 进行 测试 。 于 是 我 们 又 进行 了 一 些微 调 , 将 系统 的 默认 
提交 模式 设置 为 异步 非 等 待 模式 。 在 最 终 的 测试 结果 中 ， 每 秒 交 易 数 达 到 了 1220, CPU 使 用 率 
也 达到 了 95% 以 上 。 这 远 远 超出 了 竞争 厂商 作 浆 后 的 测试 结果 , 不 过 我 们 在 测试 过 程 中 也 有 些 很 
JE) “PERE” ITH 

这 个 案例 提 到 的 处 理 方法 ， 实 际 上 是 优化 单个 事务 规模 较 小 、 提 交 很 频繁 的 大 并 发 系统 时 
最 为 常用 的 方法 。 除 了 最 后 的 异步 提交 技术 ， 其 他 的 优化 手段 都 是 十 分 常见 的 ， 大 家 可 以 在 优 
化 类 似 系统 时 参考 使 用 。 另 外 ， 蜡 步 提 交 技 术 并 不 仅仅 适用 于 测试 环境 ， 在 实际 生产 环境 中 ， 
如 果 存 在 数据 库 实例 宕 机 后 的 数据 处 理 方案 ， 那么 就 可 以 放心 地 使 用 该 技术 来 提升 大 并 发 提交 


的 性 能 。 
18.2 IMP 导入 性 能 问题 的 分 析 


公司 的 小 杨 打 电 话 向 我 求助 ， 一 张 表 的 IMP 导入 工作 从 10 H 7 日 就 开始 了 ， 根 据 测 算 应 该 
在 10 H 8 H 23 点 左右 完成 , 但 直到 现在 (10 月 9 日 上 午 9 点 ) 仍 未 完成 。 已 经 检查 过 
DBA_EXTENTS 视图 ， 到 目前 为 止 该 表 一 共 导 入 了 18 GB 的 数据 ， 表 的 大 小 为 25 GB ， 共 包含 
2.5 亿 多 条 记录 。 

很 多 DBA 磁 到 这 类 问题 都 感到 无 从 人 手 ， 即 使 分 析出 了 问题 原因 ， 也 不 知道 该 如 何 处 理 。 
是 重新 导入 , 还 是 继续 等 待 呢 ? 到 底 还 要 多 长 时 间 才 能 完成 导入 ? 其 实 , 这 类 问题 的 分 析 方 法 并 
不 复杂 ， 涉 及 的 都 是 我 们 最 为 熟知 的 工具 和 知识 。 

首先 ， 我 问 小 杨 是 如 何 测算 导入 时 间 的 ， 他 告诉 我 是 根据 原 表 的 扩展 大 小 ， 然 后 通过 
РВА EXTENT 视图 查看 1 小 时 大 概 的 增长 数量 , 估算 出 来 的 。 原本 预计 导入 操作 10 多 个 小 时 就 
可 以 完成 ,但 实际 上 到 现在 已 经 过 去 36 个 小 时 了 ， 仍 有 近 30% 的 数据 没有 完成 导入 。 

分 析 这 个 问题 时 , 首先 需要 明确 IMP 进程 在 等 待 什么 , 通过 V$SESSION_WAIT 视图 可 以 看 
到 该 进程 总 是 在 等 待 db file sequential read 事件 。 从 这 个 等 待 事件 的 pl, p2 参数 可 以 看 出 ， 等 待 
主要 集中 在 索引 上 。 于 是 我 就 问 小 杨 ， 导 入 时 是 否 提前 建 好 了 表 和 索引 。 

回答 是 肯定 的 , 至 此 ， 这 个 问题 就 基本 被 定位 了 。 对 于 一 张大 表 来 说 ， 附 带 大 量 索 引 的 导入 
操作 速度 会 比 普通 导 和 人 操作 下 降 数 倍 ， 而 且 随 着 索引 叶 节 点 分 裂 , 在 后 期 会 变 得 更 慢 。 其 实 , 小 
杨 也 早 就 想到 了 这 方面 的 问题 ， 但 在 另外 一 台 机 器 上 进行 测试 时 ， 这 张 表 能 够 在 24 小 时 内 完成 
导入 ， 对 于 这 次 数据 迁移 ，24 小 时 完成 是 可 以 接受 的 。 为 什么 在 这 两 台 机 器 上 性 能 的 差别 会 如 
此 之 大 呢 ? 

这 并 不 难 理解 ， 通 过 AWR 报告 的 比 对 ， 我 们 很 快 就 会 发 现 ， 这 套 系统 的 UO 性 能 要 低 于 测 
试 系统 。 测 试 系统 的 db file sequential read 等 待 事件 响应 时 间 在 4 毫秒 左右 ， 而 当前 系统 的 平均 
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响应 时 间 为 9 毫秒 左右 。 另 外 ， 当 前 系统 的 LOG FILE SYNC 等 待 也 要 严重 很 多 。1/O 性 能 的 好 
坏 对 数据 导 和 操作 的 性 能 影响 是 很 大 的 。 由 于 两 套 系统 的 IO 性 能 存在 差异 ， 出 现 这 样 的 问题 也 


就 不 足 为 奇 了 。 


既然 已 经 了 解 了 IMP & AH 


能 出 现 问题 的 原因 ， 接 下 来 就 需要 估算 导 和 操作 需要 多 长 时 


间 才 可 以 完成 。 如 果 时 间 过 长 ， 就 应 该 杀 掉 现在 的 导入 进程 ， 然 后 删除 索引 ， 重 新 进行 导入 


操作 。 


由 于 之 前 进行 过 类 似 的 导入 操作 ， 因 此 我 们 知道 该 表 全 部 导入 后 ， 整 个 段 大 小 约 为 25 GB. 


而 目前 经 过 36 个 小 时 的 导入 ， 段 大 小 为 18 GB， 以 此 为 依据 ， 可 以 估算 出 导入 所 需 的 总 时 间 为 
36 + 18 x 25=50 小 时 ， 也 就 是 说 ， 导 入 工作 大 概 还 需要 14 个 小 时 才能 完成 。 实 际 上 ， 这 种 估算 


并 不 一 定 准确 ， 因 为 导入 操作 的 性 能 是 递减 的 , 而 且 这 套 系统 使 


用 的 存储 是 共享 的 ,半夜 没有 业 


务 的 时 候 和 白天 业务 量 较 大 的 时 候 , 存储 负载 是 不 同 的 。 因 此 实际 速度 可 能 会 更 慢 一 些 。 这 一 点 
可 以 通过 以 下 方法 来 验证 ， 首 先 ， 生 成 一 个 AWR 报告 ， 查 看 这 条 SQL 的 SQL. ID. 


SQL Id 


El apsed CPU 
Ti me (5) Ti me (5) 
3,509 312 


Elap per % Total 
Executions Exec (s) DB Time 
11 45.6 


Module: imp@sjzzw31 (TNS V1- V3) 


OURCE ID", "SSSS_ID' 
"INV_OFFER", 


SERT /*+NESTED TABLE SET REFS4*/ INTO "XXXX I TEM OWE" 
" XXXX ITEM TYPE 10", 
' QFFER 10", 


“CYCLE ID", 
"ОК ITEM 10") VALUES (:1, :2, 


通过 SQL ID /EJX awrsqrpt 报告 ， 用 于 进一步 分 析 这 条 SQL 的 执行 情况 。 


"XXXX 0D", 
i35 cd, БЫ 


89.7 7j wf g3d18v052 


("*XXXX ITEM 10", "ITEM S 


"MMMM DATE" 


Per Execution % Snap 


Stat Name Statement 

Elapsed Ті me (ms) 3,508,949 
CPU Ti me (ms) 312,280 
Executions 11 
Buffer Gets ү ЕЕЕ 
Disk Reads 417,661 
Parse Calls 0 
Rows 2,523,059 
User 1/0 Wait Ti me (ms) 3,198,675 
Cluster Wait Ti me (ms) 41,548 
Application Wait Ti me (ms) 0 
Concurrency Wait Ti me (ms) 61 
Invalidations 0 
Version Count 2 
Sharable Mem(KB) 59 


055.6 51.7 
N/A N/A 
229,258.8 21.5 
5,424.2 90.7 
0.0 0.0 
32,161.0 ГА 
N/A ГА 

N/ A ГА 

N/A ГА 

N/A ГА 

N/A ГА 

N/A ГА 

N/A ГА 


可 以 看 出 , 平均 每 次 执行 的 行 数 (也 就 是 每 次 插入 的 数据 量 ) 为 32767， 这 是 因为 IMP 进程 


采用 BULK INSERT 方式 插入 数据 ,根据 BUFFER 的 大 小 不 同 , 每 次 插入 的 数据 量 也 不 同 。 我 们 
可 以 在 Statement 列 中 看 到 , 在 AWR 报告 期 间 (1 小 时 ) 一 共处 理 了 2523059 行 。1 小 时 插入 250 
万 行 数据 ， 搬 入 性 能 很 差 。 通 过 同样 的 方法 ， 生 成 IMP 进程 刚刚 开始 时 的 awrsqrpt 报告 : 
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Stat Name Statement Per Execution % Snap 

Elapsed Time (ms) 1,980, 963 50218 5 3 
CPU Time (ms) 1,200,232 3,046.3 6.8 
Executions 394 N/A N/A 
Buffer Gets THEE E EE 201,683.2 6.9 
Disk Reads 903 2.3 0.2 
Parse Calls 1 0.0 0.0 
Rows TUO HHH 32,767. 0 IA 
User 1/0 Wait Ti me (ms) 20,220 N/A IA 
Cluster Wait Time (ms) 20,987 N/A IA 
Application Wait Time (ms) 2 МА ГА 
Concurrency Wait Ті те (ms) 23,900 N/A IA 
Invalidations 0 МА ГА 
Version Count 1 N/A IA 
Sharable Mem( KB) 30 N/A IA 


此 报告 中 的 Rows 超 长 了 ， 所 以 显示 的 都 是 #， 不 过 我 们 可 以 通过 Per Execution 的 数据 来 计 
Ж: 执行 次 数 与 每 次 处 理 的 记录 数 的 乘积 ， 就 是 总 记录 数 。 通 过 计算 发 现 ， 刚 开始 插入 时 每 小 
时 插入 的 数据 量 为 32767 х 394 = 12910198， 这 表明 此 时 的 插入 速度 可 以 达到 每 小 时 1291 万 条 
记录 。 较 此 数据 ， 目 前 的 插入 性 能 已 经 下 降 了 数 倍 。 

从 目前 的 情况 来 看 ， 估 计 再 过 10 个 小 时 也 无 法 完成 插入 操作 ， 我 们 可 以 通过 更 为 精确 地 计 
算 来 验证 此 观点 。 这 张 表 的 总 记录 数 为 2.5 亿 , 目前 已 经 完成 了 18/25, 还 有 7/25 的 数据 未 完成 ， 
即 约 7000 万 条 记录 未 导 和 人。 如 果 按 照 目前 的 速度 ， 每 小 时 导入 250 万 条 记录 ， 那 么 全 部 导入 还 
需要 28 个 小 时 。 

如 果 我 们 删除 所 有 的 索引 ， 然 后 重新 导入 ， 可 能 在 10 个 小 时 内 就 能 完成 ， 因 此 必须 终止 导 
和 人 操作， 重新 开始 。 

于 是 我 们 终止 了 当前 操作 ， 删 除了 表 上 的 所 有 索引 ， 然 后 截取 (truncate) 了 相关 表 ， 重 新 
进行 导入 操作 ， 并 且 在 导入 时 添加 了 INDEXES =N 条 件 ， 避 免 索引 生成 。 接 下 来 ， 手 工 编写 索 
引 创建 脚本 ， 并 行 创建 索引 。5 个 小 时 后 ， 导 入 工作 顺利 完成 。 

这 个 案例 并 不 复杂 ， 是 很 多 DBA 都 经 常 遇 到 的 。 通 过 此 案例 ， 老 白 介 绍 了 一 种 利用 AWR 
报告 计算 IMP 速度 的 方法 ， 该 方法 已 经 多 次 为 老 白 制定 决策 提供 了 帮助 。 


18.3 并行 操作 为 什么 无 法 执行 


以 前 ,在 一 次 系统 割 接 时 ,我 们 曾 碰 到 过 一 个 十 分 奇怪 的 现象 。 由 于 要 进行 系统 迁移 ， 很 多 
大 表 在 数据 导入 时 都 没有 创建 索引 ， 因 此 导入 结束 后 需要 重建 索引 。 为 了 加 快 索 引 的 创建 速度 ， 
需要 进行 并 行 创 建 。 虽 然 我 们 在 创建 索引 的 脚本 中 加 入 了 PARALLEL 40 子 名 ,但 实际 上 ,创建 
索引 的 操作 仍 是 串 行 的 。 

这 是 一 套 64 核 的 系统 ， 并 行 创 建 索引 可 以 成 倍 地 提高 速度 ， 而 无 法 使 用 并 行 严重 影响 了 制 
接 前 的 准备 工作 ， 因 此 必须 尽快 查 清 问 题 原 因 。 首 先 ， 我 们 需要 检查 并 行 的 相关 参数 设置 。 
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NAME TYPE VALUE 
fast start parallel rollback string LOW 
parallel adaptive multi user boolean TRUE 
parallel automatic tuning boolean FALSE 
parallel execution message size integer 2152 
parallel Instance group string XXXX31 
parallel max servers integer 1000 
parallel min percent i nteger 0 
parallel min servers integer 10 
parallel server boolean TRUE 
parallel server Instances integer 2 
parallel threads per cpu i nteger 2 
recovery parallelism integer 0 


可 以 看 出 ,PARALLEL 相关 的 参数 设置 并 无 问题 ,PARALLEL_MAX_SERVERS 参数 为 1000， 
PARALLEL MIN. SERVERS 参数 为 10。 通 过 ps 命令 可 以 看 出 ， 目 前 系统 只 启动 了 10 个 并 行进 
程 ， 也 就 是 PARALLEL MIN. SERVERS 参数 指定 的 数量 。 


oracle@test31: /oracl es ps Wad po 


oracle 13044 1 0 Oct 20 0:04 ora p008 test31 
oracle 13038 1 0 Oct 20 0:04 ora p005 test31 
oracle 13029 1 0 Oct 20 ? 0:04 ora p003 test31 
oracle 13027 1 0 Oct 20 ? 0:04 ora p002 test31 
oracle 6425 1 0 Oct 18 ? 0:08 ora psp0O test31 
oracle 13031 1 0 Oct 20 ? 0:04 ora_p004 test31 
oracle 13025 1 0 Oct 20 ? 0:04 ora p001 test31 
oracle 13040 1 0 Oct 20 ? 0:04 ora p006 test31 
oracle 13023 1 0 Oct 20 ? 0:04 ora p000 test31 
oracle 13046 1 0 Oct 20 ? 0:04 ora p009 test31 
oracle 13042 1 0 Oct 20 ? 0:04 ога p007 test31 


从 pr HAART 并 行进 程 的 启动 是 正常 的 。 在 ALERT LOG 日 志 中 也 没有 出 现 相关 的 错 
误 或 者 警告 信息 。 这 个 问题 确实 有 点 奇怪 , 为 了 尽快 定位 问题 , 我 们 创建 了 如 下 所 示 的 测试 环境 。 


create table xuji test tablespace sysaux as select * from dba objects ; 
alter table xuji test parallel 20; 
select count(*) from xuji test 


БЕК Ж, iit DBA OBJECTS 视图 创建 一 张 包含 6 万 多 条 记录 的 表 xuji_test， 然 后 将 这 张 表 
的 并 行 度 设置 为 20， 并 进行 一 次 COUNT(*) 操 作 ，SQL 执行 后 ， 从 VSSQLAREA 视图 中 找到 这 
条 SQL 的 SQL ID， 其 执行 计划 如 下 : 


SQL> select * from 

table(dbms xplan.display cursor('8sj2h9nsq7s4h', nul | , ADVANCED' )) 

select count(*) from xuji test 

Plan hash value: 3609358487 

| Id | Operation | Name | Rows | TQ |IN-OUT| PQ Distrib 


| 0 | SELECT STATEMENT | | | | | | 
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SORT AGGREGATE 1 | | 
PX COORDINATOR | | 
PX SEND QC (RANDOM 


PX BLOCK ITERATOR 61059 |Q1,00 | PCWC 
TABLE ACCESS FULL 61059 |Q1,00 | PCWP 


| 
| 
:TQ10000 | 1 101,00 | P->S | QC (RAND 
| 
| 
| 


1 | 

2 | | 
3 | | 
4 | SORT AGGREGATE | 1 |Q1,00 | PCWP | | 
5 | | 
6 | | 


1 - SEL$1 
PLAN_TABLE_OUTPUT 

6 - SEL$1 | XUJI TESTQSEL$1 
Outline Data 


BEGIN OUTLI NE DATA 

IGNORE OPTIM EMBEDDED HI NTS 

OPTI MI ZER FEATURES ENABLE('10.2.0.4' 
ALL ROWS 

OUTLINE LEAF( Q'SEL$1") 


PLAN TABLE OUTPUT 


FULL(@'SEL$1" "XUJI TEST'Q'SEL$1") 
END OUTLI NE DATA 


*[ 
Predicate Information (identified by operation id): 


1 - (#keys=0) COUNT() [22] 
2 - SYS OP MSR()[10] 

3 - (#keys=0) SYS OP MSR()[10] 
4 - (#keys=0) SYS OP MSR()[10] 


从 执行 计划 来 看 ， 好 像 这 条 SQL 是 并 行 查询 的 。 不 过 从 ps 结果 来 看 ， 并 行进 程 并 无 改变 : 


oracleQtest31:/oracle$ ps -ef|grep pO 
1 ? 


oracle 13044 1 0 Oct 20 7? 0:04 ora p008 test31 
oracle 13038 1 0 Oct 20 ? 0:04 ora p005 test31 
oracle 13029 1 0 Oct 20 ? 0:04 ora p003 test31 
oracle 13027 1 0 Oct 20 ? 0:04 ora p002 test31 
oracle 6425 1 0 Oct 18 ? 0:08 ora_psp0_test31 
oracle 13031 1 0 Oct 20 ? 0:04 ora_p004 test31 
oracle 13025 1 0 Oct 20 ? 0:04 ora p001 test31 
oracle 13040 1 0 Oct 20 ? 0:04 ora p006 test31 
oracle 13023 1 0 Oct 20 ? 0:04 ora p000 test31 
oracle 13046 1 0 Oct 20 ? 0:04 ora p009 test31 
oracle 13042 1 0 Oct 20 ? 0:04 ora p007 test31 
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为 了 进一步 确认 并 行 查询 是 否 发 生 ， 我 们 对 一 张 记 录 数 为 3 亿 的 大 表 进 行 了 查询 。 
select /*+ full(a) parallel( a 50) */ from xxxx a; 
此 查询 执行 了 10 分 钟 ， 在 SQL 执行 期 间 查 询 视 图 VSPX. SESSION: 


SQL» select * from v$px session; 


未 选 定 行 

从 查询 结果 来 看 ,无 并 行进 程 存在 ,因此 可 以 确定 并 行 查询 并 未 发 生 。 下 一 步 该 如 何 处 理 呢 ? 
看 来 只 能 进行 跟踪 了 ， 跟 踪 并 行 查询 可 以 使 用 隐 仿 参数 _PX_TRACE。 关 于 如 何 使 用 该 参数 来 分 
析 并 行 查询 , 可 以 参考 Metalink 文档 How to Use PX. TRACE to Check Whether Parallelism is Used 
[ID 400886.1]. 

首先 在 会 话 中 设置 PX_TRACE 参数 : 

SQL» alter session set "_px_trace"="compilation", "execution", "messaging" 


2] 
会 话 已 更 改 。 


上 述 设 置 的 含义 是 在 SQL 编译 、 执 行 和 并 行 执行 消息 传递 活动 发 生 时 进行 跟踪 。 设 置 好 参 
数 后 ， 执 行 如 下 查询 操作 : 
SQL» select count(*) from xuji test; 


COUNT( *) 
61059 


SQL 执行 结束 后 ， 在 udump 目录 下 找到 这 个 trace 文件 ， 其 内 容 如 下 : 


*** ACTION МАМЕ: () 2011-10-20 20: 43: 29. 336 

*** MODULE МАМЕ: (sql plus@test31 (TNS М1- М3) ) 2011-10-20 20: 43:29. 336 
*** SERVICE МАМЕ: (SYS$USERS) 2011-10-20 20: 43: 29. 336 

*** SESSION 10: (2720. 703) 2011-10-20 20:43:29. 336 


kkfdapdm 

pgadep:0 pdml mode:0 PQ allowed DML allowed not autonomous => not allowed 
kxfplist 

Getting Instance info for open group 
kxfralo 

serial - Instance group has no open members 


这 段 信 息 中 的 第 一 句 pgadep:0 是 每 个 trace 文件 都 包含 的 , 不 必 留 意 。 下面 的 kxfplist 和 kxfralo 
这 两 句 十 分 重要 , 其 含义 为 查找 实例 的 并 行 组 ( parallel group ), 判断 本 会 话 是 否 属于 开放 的 并 行 组 。 
如 果 会 话 的 PARALLEL_INSTANCE_GROUP 参数 指定 的 并 行 组 在 某 个 实例 中 未 设置 ， 那 么 就 不 能 
使 用 并 行 查询 。 从 kxfralo 的 结果 可 以 看 出 , 最 终 选择 的 执行 方式 是 串 行 (serial ), 而 选择 串 行 的 原 
是 “Instance group has no open members”， 也 就 是 说 当前 PARALLEL INSTANCE GROUP 参数 指 
定 的 组 不 属于 INSTANCE, GROUPS 参数 指定 的 组 。 难 道 是 PARALLEL, INSTANCE. GROUP 参数 
设置 的 问题 吗 ? 我 们 再 来 看 看 下 面 的 信息 : 


SQL> show parameter Instance_group 
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NAME TYPE VALUE 


Instance groups string test3,test31 
parallel lnstance group string test31 


这 里 好 像 并 没有 什么 问题 , PARALLEL. INSTANCE GROUP 设置 为 test31, 而 实例 的 组 设置 
为 test3 和 test31 。 尽 管 根据 跟踪 结果 定位 的 并 行 查询 无 法 执行 的 原因 是 
PARALLEL_INSTANCE_GROUP 参数 设置 存在 问题 ， 但 从 参数 本 身 来 看 ， 并 没有 任何 问题 ， 难 
道 磁 到 灵异 事件 了 ? 其实 Oracle 根本 不 可 能 存在 灵异 事件 , 肯定 是 我 们 忽略 了 什么 。 通 过 一 种 简 
单 有 效 的 方法 可 以 验证 参数 设置 是 否 存在 问题 ， 即 查看 正常 数据 库 中 的 参数 设置 。 


SQL» show parameter Instance group 
NAME TYPE VALUE 


Instance groups string testl, test11 
parallel Instance group string test11 


从 表面 来 看 ， 好 像 并 没有 不 同 。 但 经 过 5 分 钟 的 反复 比 对 ， 我 终于 发 现 正确 的 
INSTANCE GROUPS 参数 的 两 个 组 之 间 有 一 个 空格 ， 这 可 能 就 是 问题 所 在 。 下 一 步 ， 我 们 来 验 
证 这 个 空格 是 否 和 参数 设置 不 同 有 关 。 在 这 两 个 系统 上 ， 分 别 生成 一 个 ре 文件 ， 来 查看 参数 。 

create pfilez'/tmp/init.ora' from spfile 

问题 系统 的 参数 设置 为 : 

Instance groupsz'test3,test31 

正常 系统 的 参数 设置 为 : 

Instance groups='testl','testl1l' 

在 参数 文件 中 , 结果 就 更 清晰 了 。 一 个 是 单 引 号 括 住 了 两 个 组 ; 另 一 个 是 每 个 组 分 别 用 单 引 
号 括 起 来 ， 并 用 逗号 分 割 。 第 一 种 配置 实际 上 是 将 INSTANCE. GROUPS. 参数 设置 为 一 个 名 为 
test3,test31 的 组 ( 逗号 是 组 成 组 名 的 合法 字符 )， 可 以 通过 以 下 示例 来 验证 。 

SQL» alter session set "_px_trace"="compilation", "execution", "messaging" 

会 话 已 更 改 。 

SQL» alter session set parallel Instance group='test3,test31' 


会 话 已 更 改 。 
SQL» select count(*) from xuji test 


于 是 ， 我 们 将 会 话 的 PARALLEL INSTANCE GROUP 参数 设置 为 test3,test31， 使 之 符合 并 
行 查询 的 条 件 。 令 人 兴奋 的 是 ，trace 文件 发 生 了 改变 。 


*** ACTION NAME:() 2011-10-20 20:53:48.616 
*** MODULE NAME:(sqlplusQtest31 (TNS V1-V3)) 2011-10-20 20:53:48.616 
*** SERVICE NAME: (SYS$USERS) 2011-10-20 20:53:48.616 
*** SESSION 10: (4121. 314) 2011-10-20 20:53:48.616 
kkfdapdm 
pgadep:0 pdml mode:0 PQ allowed DML allowed not autonomous => not allowe d 
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kxfplist 

Getting Instance info for open group 

kxfrSyslnfo 

DOP trace -- compute default DOP from systeminfo 
# Instance alive = 1 (kxfrsnins 

kxfrDefault DOP 
DOP Trace -- compute default DOP 


# CPU = 64 

Threads/CPU = 2 ("parallel_threads_per_cpu') 
default DOP = 128 (# CPU * Threads/ CPU 

default DOP = 128 (DOP * # Instance) 

kxfrSyslnfo 

system default DOP = 128 (from kxfrDefaultDOP()) 
kxfralo 

DOP trace -- requested thread from best ref obj = 20 (from kxfrisBestRef 
0) 
kxfralo 

threads requested = 20 (from kxfrComputeThread()) 
kxfralo 

adjusted no. threads - 20 (from kxfrAdj ust DOP()) 
kxfralo 

about to allocate 20 slaves 
kxfrAllocSlaves 


DOP trace -- call kxfpgsg to get 20 slaves 
kxfpgsg 
num server requested = 20 
kxf plist 
Getting Instance info for open group 
kxfpiinfo 
inst[cpus: mxsl v] 
1[64:1000] 
kxfpclinfo 
п (оаа: user: pct: fact) aff 
103: 0:100: 2133) 
kxf pAdapt DOP 
Requested=20 Granted=20 Target=512 Load=3 Default=128 users=0 sets=l 
kxfpgsg 

getting 1 sets of 20 threads, client parallel query execution flg=0x30 
Height=20, Affinity List Size=0, inst total =1, coord=1 

Insts 1 

Threads 20 

kxfpglsrv 
trying to get slave P000 on Instance 1 


Got It. 1 so far. 
trying to get slave P001 on Instance 1 
Got It. 2 so far. 


trying to get slave P002 on Instance 1 


183 并行 操 作为 什么 无 法 执行 419 


Got It. 3 so far. 


kxfpglsrv 

trying to get slave P003 on Instance 1 
kxfpglsg 

Got It. 4 so far. 

kxfpglsrv 

trying to get slave P004 оп Instance 1 
kxfpglsg 

Got It. 5 so far. 

kxfpglsrv 

trying to get slave P005 on Instance 1 
kxfpglsg 

Got It. 6 so far. 

kxfpglsrv 

trying to get slave P006 on Instance 1 
kxfpglsg 

Got It. 7 so far. 

kxfpglsrv 

trying to get slave P007 on Instance 1 
kxfpglsg 

Got It. 8 so far. 

kxfpglsrv 

trying to get slave P008 on Instance 1 
kxfpglsg 

Got It. 9 so far. 

kxfpglsrv 


trying to get slave P009 on Instance 1 


看 来 我 们 的 猜测 是 正确 的 , 问题 解决 了 。 由 于 修改 INSTANCE, GROUPS 参数 需要 重启 实例 ， 

此 我 们 可 以 通过 会 话 级 修改 PARALLEL_INSTANCE_GROUP 参数 来 规避 这 个 问题 ， 等 到 可 以 

重启 实例 时 再 彻底 解决 该 问题 

后 来 我 在 Metalink 上 找到 了 一 篇 相关 的 文档 ( After changing the init parameter Instance 

ROUPS, queries are no longer being executed in parallel [ID 750645.1] )， 正 好 是 讲述 这 个 问题 的 。 
这 篇 文档 指出 ，INSTANCE_GROUPS 参数 设置 错误 将 会 导致 并 行 执行 无 法 正常 工作 。 


Changed the initialization parameter settings for the parameters Instance GROUPS and 
PARALLEL Instance GROUP. Now the parameters are as follows: 

* Instance groupsz' MYRAC, MYRACI, MYRAC2, MYRAC3 
MYRACl.parallel Instance groupz' MYRACI' 

MYRAC2.parallel Instance groupz' MYRAC2' 

MYRAC3.parallel Instance groupz' MYRAC3' 


After restarting the Instances, parallel execution is disabled on all Instances. 
Parallel query processes do not get spawned even when the execution plan shows parallel. 


此 外 ， 文 章 还 指出 ， 要 解决 这 一 问题 ， 需 要 对 INSTANCE. GROUPS 参数 进行 如 下 调整 ; 


1. change the value of Instance groups in the pfile or spfile 

eg for spfile: 

alter system set Instance groupsz' MYRAC',' MYRACI', ' MYRAC2',' MYRAC3' SCOPE=SPFILE 
SI D='*' 


2. restart each Instance one at a time (to avoid downtime 


You should now be able to execute queries in parallel again, 


这 个 案例 看 起 来 十 分 简单 ， 并 没有 什么 技术 含量 。 不 过 如 果 第 一 次 碰 到 这 样 的 案例 ,可 能 就 
是 一 个 灵异 事件 。 因 此 ， 首 先 我 们 要 明确 ， 任 何不 正常 的 事件 肯定 存在 其 错误 的 地 方 ， 

E. 不 太 容 易 被 察觉 而 已 。 碰 到 这 样 的 问题 时 ， 要 采取 主动 的 手段 去 进一步 
了 跟踪 是 最 佳 的 分 析 方法 ， 另 外 也 还 可 以 采用 排除 法 帮助 分 析 。 


SQL 优化 


SQL 优化 一 直 是 大 多 数 DBA 十 分 头痛 的 问题 ， 很 多 DBA 一 直 不 敢 涉 猎 这 个 领域 。 这 是 因 
为 绝 大 多 数 DBA 都 没有 应 用 开发 的 经 验 ， 另 外 ， 部 分 DBA 甚至 没有 书写 复杂 SQL 的 经 验 。 

实际 上 ，SQL 优化 并 不 是 一 件 十 分 复杂 的 事情 ,而 只 是 一 项 比较 繁琐 的 工作 。 只 要 我 们 掌握 
T SQL 分 析 的 方法 ， 并 且 有 足够 的 耐心 ， 就 能 够 成 为 一 个 SQL 优化 的 高 手 。 本 章 将 通过 几 个 案 
例 介绍 SQL 分 析 和 优化 的 方法 , 大 家 可 以 通过 这 些 案例 学 习 到 相关 的 分 析 技 巧 ,并 进行 一 些 SQL 
优化 实践 。 在 完成 了 数 十 条 甚至 上 百 条 SQL 的 分 析 优化 工作 后 ， 你 很 可 能 就 会 成 为 一 名 SQL 优 
化 高 手 。 


19.1 一 个 常用 的 SQL 优化 方法 


如 果 我 们 在 АМК 报告 中 发 现 某 条 SQL 的 开销 很 大 ， 该 如 何 处 理 呢 ? 比如 ， 看 到 如 下 信息 : 


SQL ordered by Gets DB/Inst: SJZZzW3/sjzzw3l Snaps: 560-561 

-> Resources reported for PL/SQL code includes the resources used by all SQL 
statements called by the code. 

-> Total Buffer Gets: 1,234, 841, 780 


-> Captured SQL account for 83.2% of Tota 
Gets CPU Elapsed 
Buffer Gets Executions per Exec %T ot al Time (s) Time (s) SQL Id 
372,748, 885 25, 348 14,705. 3 30.2 3474.04 3582.40 bxta?7sv1fzd4f 


Module: send direct @wxjfappl (TNS V1- V3) 
SELECT S SEND ID, nvl(S ID, 0) S ID, пу (А NBR, '0') 
A МВА, nvl (BAL, 0) BAL, nvl(AM, 0) AMO 
nvi (E_ DATE, '20001001') E DATE, MT ID, STATE 
nvi (M CONTENT, ' ') M CONTENT, nvl(B MODE ID, 2) B MODE 


这 条 SQL 在 一 个 小 时 内 执行 了 25 348 次 ， 占 整个 系统 的 BUFFER GET 总 量 的 30.2%. “EXT 
系统 资源 的 消耗 是 非常 大 的 ， 如果 能 够 优化 , 将 使 系统 总 体 的 性 能 获得 大 幅 提 升 。 对 于 这 样 一 条 
典型 的 SQL， 我 们 该 怎样 进行 优化 呢 ? 首先 需要 格式 化 SQL 语句 ， 使 之 更 为 清晰 。 格 式 化 SQL 
可 以 借助 工具 来 完成 ，PL/SQL DEVELOPER, TOAD 以 及 Oracle SQL DEVELOPER 都 有 格式 化 
SQL 的 工具 。 如 果 找 不 到 合适 的 工具 ， 也 可 以 手工 进行 格式 化 。 手 工 格式 化 是 老 白 常用 的 方法 。 
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在 格式 化 SQL 的 时 候 ，SELECT 语句 后 面 的 字段 一 般 不 是 很 关键 ， 最 关键 的 是 FROM 语句 后 面 


的 表 以 及 WHERE 语句 后 面 的 条 件 。 


在 文本 格式 的 AWR 报告 中 ， 我 们 看 到 的 SQL 往往 是 不 完整 的 (在 HTML 格式 的 文件 中 能 
够 看 到 较为 完整 的 SQL )， 不 过 可 以 通过 awrsqrpt 工具 来 生成 更 为 详细 的 信息 。 在 awrsqrpt 报告 


中 找到 完整 的 SQL 语句 ， 然 后 对 其 进行 格式 化 : 


SELECT = 
FROM 
(SELECT A.*, B.C SERVI CE 
FROM AAAAAAAA A, BBBBBBBB B 
WHERE 
А. STATE = :1 AND A. NETWORK ID in 
select to number(attr value) 
from a sms attr where attr type - 1) AND 
A.MSG TYPE ID not in (2, 22, 23, 24, 25, 27) AND 
A.SERV ID >= :2 AND 
A.SERV ID <= :3 AND 
A.MSG TYPE 10 = B.MSG TYPE 10 AND 
B.STATE = '10A' AND 
f get valid send sms time(B.valid ti me) = 0 AND 
SYSDATE >= NVL(A. SEND SUCCESS DATE, SYSDATE - B.SM INTERVAL / 24) + 
B.SM INTERVAL / 24 
ORDER BY NVL(A. GENERATE FLAG, 0), B.S PRIORITY, B.PRIORITY, A.S SEND ID, 
A.SERV ID, NVL(A. SEND SUCCESS DATE, TO DATE('19000101', 'YYYYMMDD 
')) 


WHERE ROWNUM <= :4 


可 以 看 出 , A 表 上 的 过 滤 条 件 比 较 多 , Н, ASSTATE=:1 以 及 ASSERV_ID>=:2 AND A.SERV_ 


ID<=:3 都 使 用 了 绑 定 变量 。 


SQL> select * from 


table(dbms_xplan.display_cursor('bxta7svlfzd4f',null,'ADVANCED' ) ) 


‚.. WAKAS фл... 
Plan hash value: 3446859354 


如 果 需 要 了 解 该 SQL 中 绑 定 变量 的 取 值 情况 ， 可 以 进行 如 下 操作 : 


SELECT STATEMENT 
COUNT STOPKEY 

VI EW 
FILTER 

SORT ORDER BY 

HASH JOIN SEM 

NESTED LOOPS 

TABLE ACCESS BY GLOBAL INDEX ROW D 
RANGE SCAN 

ACCESS BY INDEX ROWI D 

UNI QUE SCAN 

ACCESS FULL 


ке C5 «o со — сэ Un > CO го ка c 


m 


S SEND 

|DX SMS SEND SERV 
S SEND TYPE 

PK S SEND TYPE 10 
A SMS ATTR 
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Query 


m 


Outli 


pet 


*f 


Peeke 


4 
Predi 


8 - 


ке C5 «o оо — co r ка 


— Cn CO ко ка 


Block Name / Object Alias (identified by operation id): 
SEL$7EB7D0CF 
SEL$2A90E61B / from$ subquery$ 001QSEL$1 
SEL$2A90E61B 
SEL$2A90E61B | AQSEL$2 
SEL$2A90E61B | AQSEL$2 
SEL$2A90E61B | B@SEL$2 
SEL$2A90E61B / B@SEL$2 
SEL$2A90E61B / A_SMS_ATTR@SEL$3 


ne Data 


BEGIN OUTLINE DATA 

| GNORE OPTIM EMBEDDED HI NTS 

OPT ZER FEATURES ENABLE('10.2.0.4' 
ALL ROWS 
UTLI NE LEAF(Q'SEL$2A90E61B" 

ULL PRED(Q'SEL$1' "from$ subquery$ 001" 1) 

UTLI NE LEAF( @"SEL$7EB7D0CF") 

UTLI NE( @"SEL$BE5C8E5F") 

EST( @'SEL$3") 

UTLI NE( @"SEL$1") 

UTLI NE( @"SEL$2") 

LI NE( Q'SEL$3") 

ACCESS(Q'SELS$7EB7DOCF" "from$ subquery$ 001'Q'SEL$1") 


TT Zzooocoov])S 
Oc 


FULL(Q'SEL$2A90E61B" "A SMS ATTR'Q'SEL$3') 


LEADI NG( GQ'SELS$2A90EG1B" "А" @'SEL$2" "B'Q'SEL$2" "A SMS ATTR'Q'SEL$3") 


USE NL(Q'SEL$2A90E618" "B"@"SEL$2") 
USE HASH(Q'SELS2A90E618" "A SMS ATTR"@'SEL$3") 
END OUTLINE DATA 


d Binds (identified by position): 


1 : 

:2 (NUMBER): 101112894255 
:3 (NUMBER): 101113864255 
4 
e 


: 1000 
nformation (identified by operation id): 


filter( ROWNUM<=: 4) 

filter("F GET VALID SEND SMS TI ME" (" VALID TI ME") =0 
filter(:2<=: 3) 
access("A"."NETWORK_|D"=TO_NUMBER("ATTR_VALUE") ) 


<>25 AND "A". " М6 ТҮРЕ 1р" <>27) ) 
access("A"."SERV_ID">=:2 AND "А". "SERV 10" <=: 3) 


DEX_RS_ASC @'SEL$2A90E61B" "A'Q'SEL$2" ("S_SEND"."SERV_ID")) 
DEX_RS_ASC( @'SEL$2A90E61B" "B"@'SEL$2" ("5 SEND TYPE'."MSG TYPE ID'J) 


- filter((" A*. "ТАТЕ" =: 1 AND "А", "MSG TYPE 10" <>2 AND "A". "MSG TYPE 10" <>22 AND 
"А". "М6 TYPE 10" <>23 AND "А". "MSG TYPE 10" <>24 AND "А", " М6 TYPE ID" 
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9 - filter(("B"."STATE"='10A' AND NVL("A"."SEND_SUCCESS_ DATE", SYSDATE@! - "В". "SM_ 
NTERVAL"/24)+"B". "SM INTERVAL"/24<=SYS DATE@!)) 

10 - access("A"."MSG TYPE ID'z"B'."MSG TYPE ID") 

filter((*B'."MSG TYPE 1р" <>2 AND 'B'."MSG TYPE 10" <>22 AND "B"."MSG TYPE ID" 

<>23 AND "B'."MSG TYPE 10" <>24 AND "В". " М56 TYPE 10" <>25 AND "В". "MSG_ 
TYPE | D" <>27)) 

11 - filter("ATTR ТҮРЕ" z1) 


Column Projec 


ion Information (identified by operation id): 


-"SMS SEND |D'[NUMBER,22], "SERV | D'[ NUMBER, 22], "АСС NBR'[ VARCHAR2, 32], "BALANCE" 
[NUMBER, 22], "AMOUNT" [NUMBER, 22], "EXP DATE"[VARCHAR2,8], "MSG TYPE ID'[ NUMBER 
22], "STATE"[ NUMBER, 22], "MSG CONTENT"[VARCHAR2, 1024], "BILLING MODE | D"[ NUMBER 
22], "NETWORK | D" [ NUMBER, 22], "ACCT CREDI T" [ NUMBER, 22], " SOURCE. SERV | D" [ NUMBER, 22], 
"CALL SERVI СЕ" [ VARCHAR2, 30 

"SMS SEND 1 D"[ NUMBER, 22], "SERV | D'[ NUMBER, 22], "ACC NBR'[VARCHAR2, 32], "BALANCE" 
[NUMBER, 22], "AMOUNT"[ NUMBER, 22] 

"EXP. DATE"[VARCHAR2,8], "MSG TYPE |D'[NUMBER,22], " ЅТАТЕ" [ МОМВЕЋ, 22], " MSG. CONTENT" 
[VARCHAR2,1024], "BILLING MODE [D'[NUMBER,22], "NETWORK | D'[NUMBER, 22], "ACCT_ 

CREDI T" [ NUMBER, 22], "SOURCE SERV 10" [ NUMBER, 22], "CALL SERVI CE"[ VARCHAR2, 30] 
"VALID TI ME" [ VARCHAR2, 128 

-'A'.'SMS SEND I D'[ NUMBER, 22], "А". " SERV 10" [ NUMBER, 22], "В". "VALID TI ME" [ VARCHAR2 
128], "B'.'CALL SERVI CE'[ VARCHAR2, 30], "А". "АСС NBR'[VARCHAR2, 32], "А". "BALANCE" 
[NUMBER, 22], "А". "AMOUNT" [ NUMBER, 22], "А". " ЕХР DATE"[VARCHAR2, 8], "А". "MSG TYPE 10" 
[ NUMBER, 22], "A'."STATE"[NUMBER, 22], "A'."MSG CONTENT"[VARCHAR2, 1024], "А" 
"BILLING MODE 10" [ МОМВЕВ, 22], "А". "NETWORK 1 D"[NUMBER, 22], "A'."ACCT CREDIT" 
[NUMBER,22], "A". "SOURCE SERV 10" [ NUMBER, 22 
(#keys=6) NVL("A"."GENERATE FLAG", 0) [22], "B'."SMS PRIORITY"[NUMBER, 22], "B" 
"PRI ORI TY"[NUMBER, 22], "A"."SMS SEND 10" [ NUMBER, 22], "A"."SERV ID'"[ NUMBER, 22] 
NVL("A". "SEND SUCCESS РАТЕ", TO DATE(' 1900-01-01 00:00:00', ' ѕуууу- mm dd hh24: 
m:ss'))[7], "B'."VALID TI ME'[VARCHAR2, 128], "В". "СА SERVI CE"[ VARCHAR2, 30] 
"A", "АСС МВА" [ VARCHAR2, 32], "A". " BALANCE" [ NUMBER, 22], "А". " AMOUNT" [ NUMBER, 22] 
"А", "EXP. DATE"[VARCHAR2, 8], "A"."MSG TYPE I D'[ NUMBER, 22], "А". " STATE" [ NUMBER, 
22], '"A'.'MSG CONTENT"[VARCHAR2, 1024], "A"."BILLING MODE 10" [ NUMBER, 22], "A" 
" NETWORK | D'[ NUMBER, 22], "A'."ACCT CREDI T"[ NUMBER, 22], "А". "SOURCE SERV ID" 

[ NUMBER, 22] 

-(#keys=1) 'A'."NETWORK I D'[ NUMBER, 22], "A'."SMS SEND 10" [ МОМВЕВ, 22], "A" 

"SERV I D'[ NUMBER, 22], "А". "АСС NBR'[VARCHAR2, 32], "А". " BALANCE" [ NUMBER, 22] 


"А". "AMOUNT"[ NUMBER, 22], "A'."EXP DATE'[VARCHAR2,8], '"A'."MSG TYPE 10" [NUMBER, 


22 


"AUS. " BALANCE" 


[ NUMBER, 22], 


nad "AMOUNT" [ 


22], 


"А", "GENERATE FLAG"[ NUMBER, 22], 
[NUMBER, 22], "В", "5 М5 РАІ ORI TY"[ NUMBER, 
"B". "VALI D_ 

[ NUMBER, 22], "А". "АСС NBR'[V 

[NUMBER, 22], "А", "ЕХР DATE"[VARCHAR2,8 
"STATE" [ NUMBER, 22], "A'."SE 

1024], "A". "BILLING MODE ID'[NUMBER, 22], 
CREDI T"[ NUMBER, 22], "A'."GENERATE FLAG'[ 
22], "В". "PRILORI ТҮ" [NUMBER, 22], "В". "SMS. 
[VARCHAR2,30], "B'."VALID TI МЕ" [ VARCHAR2, 128] 
- "А", "5 М5 SEND I D'[ NUMBER, 22], "A"."SERV I 


, "A'."STATE"[ NUMBER, 22], "A"."SEND SUCCESS DATE'[DATE, 7], "А". " М6 CONTENT" 
[ VARCHAR2, 1024], "A'."BILLING MODE ID'[NUMBER, 22], "А". "АССТ CREDI T"[ NUMBER, 22], 
"A'"."SOURCE SERV ID'[NUMBER, 22], 
- "В". "CALL SERVI CE'[ VARCHAR2, 30], 
TI МЕ" [ VARCHAR2, 128] 6 - "А". "5 М5 SEND ТО" [ МОМВЕЋ, 22], 'A'."SERV ID" 
ARCHAR2, 32], "А". "BALANCE"[ NUMBER, 22], "А". "AMOUNT" 
, !A*."MSG TYPE Тр" [ NUMBER, 22], 
D SUCCESS РАТЕ" [ РАТЕ, 7], "А". " М5С CONTENT" [ VARCHAR2, 
"A". "NETWORK | D'[ NUMBER, 22], "А". "АССТ_ 


"В". "РАГОКІТҮ" 


"A". 


UMBER,22],"A"."SOURCE_SERV_ID'INUMBER, 
PRI ORI TY" [ NUMBER, 22], "В". " CALL SERVI CE" 


D'[NUMBER, 22], "А". "АСС NBR'[ VARCHAR2, 32], 
UMBER, 22], "A'."'EXP DATE"[VARCHAR2, 8], 
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"A". " МС ТҮРЕ Тр" [ NUMBER, 22], "A"."STATE"[NUMBER, 22], "A". " ЕМО SUCCESS DATE" 
[DATE, 7], 'A'."MSG CONTENT'[VARCHAR2,1024], "A'."BILLING MODE ID'[ NUMBER, 22] 
"А", "NETWORK I D'[ NUMBER, 22], "A'."ACCT CREDI T'[ NUMBER, 22], "А". " СЕМЕКАТЕ FLAG" 
[NUMBER, 22], 'A'"."SOURCE SERV ID'[ NUMBER, 22] 
8- "A". ROW D[ ROWI D, 10], "A"."SERV ID'[ NUMBER, 22] 
9- "B'.'PRIORITY'[NUMBER, 22], "B"."SMS_ PRIORI TY"[ NUMBER, 22], "B'.'CALL SERVI СЕ" 
[VARCHAR2, 30], "'B'."VALID TI МЕ" [ VARCHAR2, 128] 
10 - "В". ROW! D[ ROW D, 10] 
11 - "ATTR VALUE"[VARCHAR2, 12] 
138 rows selected 


select * from table ( dbms, xplan.display. cursor (SQL Id';null, Е )) 语 句 可 以 返回 SQL 
执行 计划 的 详细 信息 和 具体 细节 ， 其 中 也 包含 了 绑 定 变量 的 信息 。 这 条 SQL 中 4 个 绑 定 变量 的 
详细 信息 如 下 


Peeked Binds (identified by position): 


(NUMBER): 0 

(NUMBER): 101112894255 
(NUMBER): 101113864255 
(NUMBER): 1000 


其 中 ，STATE 字段 的 取 值 是 0，SERV_ID 的 上 下 边界 是 10 112 894 255 ~ 10 113 864 255, mi 
ROWNUM 是 小 于 1000 的 。 从 这 几 个 数据 可 以 看 出 ，SERV_ID 的 过 滤 条 件 范 围 较为 广泛 。 目 前 
的 SQL 执行 计划 中 , 对 A 表 的 访问 是 对 SERV_ID 的 索引 进行 范围 扫描 , 符合 条 件 的 记录 查找 A 
表 再 进行 扫描 ， 然 后 和 B 表 做 航 套 循环 ， 这 两 个 表 连 接 的 结果 再 和 C 表 做 散 列 连接 。 这 个 执行 
计划 是 否 合理 呢 ? 我 们 来 看 看 awrsqrpt 报告 中 的 SQL 统计 信息 : 


ъ оо м ка 
FJ оо м ка 


Plan Statistics DB/Inst: SJZZW3[sjzzw3l Snaps: 560-561 
> % Total DB Ti me is the Elapsed Ti me of the SQL statement divided 
into the Total Database Time multiplied by 100 
Stat Name Statement Per Execution % Snap 
Elapsed Ti me (ms) 3,582,402 141.3 8.1 
CPU Ti me (ms) 3,414,041 137.1 12.2 
Executions 25,348 N/A ГА 
Buffer Gets TEE SESS 14,705.3 30.2 
Disk Reads 31 0.0 0.0 
Parse Calls 25,341 1.0 0.1 
Rows 1,445 0.1 ГА 
User 1/0 Wait Ti me (ms) 261 N/A [А 
Cluster Wait Ti me (ms) 14 N/A ГА 
Application Wait Ті те (ms) 0 N/A ГА 
Concurrency Wait Ті ме (ms) 404 N/A IA 
Invalidations 0 N/A ГА 
Version Count 1 МА ГА 
Sharable Mem(KB) 68 N/A IA 


在 这 里 我 们 可 以 看 到 ， 平 均 每 次 执行 的 BUFFER GET 为 14 705 次 ， 这 是 很 大 的 数字 ， 而 平 
均 每 次 执行 返回 的 记录 数 是 0.1。 这 说 明 大 多 数 的 SQL 执行 都 返回 了 0 条 记录 ， 也 就 说 明 可 能 存 19 
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在 过 滤 性 很 强 的 条 件 。 于 是 ， 我 们 首先 想到 了 STATE 字段 ， 从 字面 含义 来 看 ， 该 字段 是 一 个 值 
域 范围 很 小 的 字段 , 一 般 来 说 过 滤 性 不 会 太 好 。 不 过 是 否 存 在 一 种 可 能 , 就 是 这 个 字段 是 倾斜 的 ， 
正好 执行 这 条 SQL 所 对 应 的 STATE 值 在 A 表 中 的 记录 数 很 少 。 针 对 此 猜测 , 我 们 可 以 进行 验证 : 


SQL» select count(*),state from aaaaaa group by state 


COUNT ( *) STATE 
21247 1 
100797 0 


可 以 看 出 ,这 个 字段 只 有 两 个 取 值 ， 而 且 确 实 是 倾斜 的 , 不 过 刚才 在 绑 定 变量 中 我 们 已 经 看 
到 了 ，STATE=0， 正 好 是 记录 数 较 多 的 那个 取 值 。 看 来 STATE 字段 并 不 是 一 个 很 好 的 过 滤 条 件 ， 
那么 下 一 步 就 需要 查看 其 他 的 过 滤 条 件 : 

WHERE 
A.STATE = :1 AND A. NETWORK ID in 
(select to number(attr value) 
from cccccc where attr type - 1) AND 
A.MSG TYPE 10 not in (2, 22, 23, 24, 25, 27) AND 
A.SERV 1р >= :2 AND 
A.SERV ID <= :3 AND 


如 果 STATE 再 加 上 MSG. TYPE _ ID， 这样 的 组 合 条 件 的 效果 如 何 呢 ? 
SQL» SELECT count(*) 


2 FROM AAAAAA A 
3 WHERE 
4 A.STATE = 0 AND 
A.MSG TYPE ID not in (2, 22, 23, 24, 25, 27); 
COUNT *) 
1830 


结果 集 还 是 有 1830 条 记录 ， 因 此 效果 仍 不 够 理想 ， 这 里 面 还 有 一 个 A. NETWORK ID 的 过 
滤 条 件 ， 不 过 此 过 滤 条 件 是 针对 一 个 子 查询 的 IN 操作 。 幸 和 运 的 是 ， 这 个 子 查询 是 一 个 固定 条 件 
的 查询 ， 我 们 来 看 看 它 的 结果 : 


SQL» select to number(attr value) 
2 from OWNERI.a sms attr where attr type = 1 


TO NUMBER(ATTR VALUE) 


如 果 带 上 这 个 子 查询 ， 查 询 结果 又 如 何 呢 ? 


SQL» SELECT count(*) 
2 FROM OWNERI.S SEND A 
3 WHERE 
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4 A.STATE = 0 AND A. NETWORK ID in 
(select to number(attr value) 
from OWNERI.a sms attr where attr type = 1) AND 
A.MSG TYPE ID not in (2, 22, 23, 24, 25, 27); 
COUNT ( *) 


我 们 发 现 这 个 查询 的 结果 经 常 是 0， 不 过 有 时 候 会 是 1800 左右 。 这 说 明 这 个 业务 模块 可 能 
是 处 理 完毕 后 修改 状态 位 的 模块 。 大 多 数 情 况 下 ， 这 个 查询 返回 的 结果 集 是 0， 少数 情况 返回 的 
结果 集 不 到 2000 条 记录 。 那 么 ， 另 外 一 个 过 滤 条 件 SERV. ID 的 过 滤 性 又 如 何 呢 ? 

SQL» SELECT count(* 


2 FROM OWNERI.S SEND A 
3 WHERE 
4 a.serv_id>=101112894255 and 
a.serv_id<=101113864255; 
5 
COUNT ( *) 
14664 


明显 这 个 过 滤 条 件 的 过 滤 性 不 如 前 面 的 STATE-MSG TYPE Ір 组合。 再 进一步 思考 ， 如 果 
采取 STATE+MSG_TYPE_ID+SERV_ID 的 组 合作 为 过 滤 和 条件， 效果 会 如 何 呢 ? 
SQL» SELECT count(*) 


2 FROM OWNERI.S SEND A 
3 WHERE 
4 A.STATE - 0 AND 


A.MSG TYPE 10 not in (2, 22, 23, 24, 25, 27) and 
a.serv_id>=101112894255 and 
a.serv_id<=101113864255; 
5 6 7 
COUNT ( *) 


这 个 组 合 的 效果 要 比 前 面 的 过 滤 性 更 好 。 因 此 , 如果 要 优化 这 条 SQL, 最 为 简单 的 方法 是 创 
建 这 三 个 条 件 的 复合 索引 ， 那 么 下 一 步 我 们 就 要 考虑 这 三 个 字段 的 先后 顺序 。 如 果 单 纯 从 这 条 
SQL 来 考虑 ， 由 于 STATE 的 条 件 是 等 于 ， 因 此 将 其 作为 索引 的 首 字段 具有 比较 好 的 效率 ， 但 第 
二 个 字段 是 使 用 SERV_ID 还 是 MSG. TYPE ID J£? 我 们 可 以 通过 如 下 查询 来 查看 到 底 哪个 条 件 
的 过 滤 性 更 强 : 


SQL> SELECT COUNT(*) FROM OWNER1.S_SEND A 
2 WHERE STATE=0 AND A. MSG TYPE 10 not in (2, 22, 23, 24, 25, 27) 


COUNT( *) 


SQL» SELECT COUNT(*) FROM OWNERI.S SEND A 
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2 WHERE STATE=0 AND a.serv_id>=101112894255 and 
3 a.serv_id<=101113864255; 


COUNT( *) 


针对 上 述 结果 ， 我 们 发 现 MSG TYPE ID 的 过 滤 性 更 好 ， 因 此 它 更 适合 作为 第 二 索引 字段 。 
不 过 上 面 的 分 析 都 是 基于 本 SQL 的 ， 如 果 在 创建 索引 时 还 要 兼顾 其 他 的 SQL， 那 么 设计 索引 的 
方式 可 能 就 会 有 所 不 同 ， 对 于 这 条 SQL 来 说 ， 虽 然 采 用 另外 一 种 方式 创建 的 包含 这 三 个 字段 的 
复合 索引 可 能 不 是 最 佳 的 ， 但 是 对 于 整个 系统 来 说 ， 就 可 能 是 最 好 的 。 

上 述 案例 介绍 了 最 简单 的 一 种 SQL 优化 方式 ,在 多 数 情况 下 ， 我 们 很 难 让 开发 商 去 修改 应 
用 ， 因 此 索引 的 优化 在 SQL 优化 工作 中 尤为 重要 。 在 分 析 时 ， 我 们 发 现 了 主 表 (AR) EWR 
引 范 围 扫 描 不 是 特别 合理 ， 并 且 存 在 很 多 过 滤 条 件 ， 因 此 我 们 会 考虑 是 否 换 一 个 索引 来 提高 这 
一 层 的 扫描 效率 。 而 索引 的 创建 是 与 其 过 滤 效 率 有 关 的 ， 索 引 的 过 滤 效 率 不 能 仅仅 从 字段 的 选 
择 性 上 来 考虑 ， 应 该 针对 具体 问题 进行 相应 分 析 ， 以 当前 SQL 作为 前 提 条 件 ， 来 判断 哪些 字段 
的 组 合 才 是 最 佳 的 。 在 进行 这 类 SQL 优化 时 ， 索 引 字 段 的 选择 性 分 析 就 十 分 重要 了 。 并 不 是 传 
统 意 义 上 的 某 个 字段 的 值 域 越 广 ， 选 择 性 就 越 强 。 对 于 某 些 具体 的 情况 ， 需 要 根据 业务 的 特点 
进行 分 析 ， 这 样 得 到 的 结论 才 更 为 准确 。 从 值 域 以 及 全 表 范 围 来 看 ，SERV_ID 的 选择 性 肯定 好 
于 STATE, 但 是 在 本 SQL 中 ， 对 于 SERV. ID 仅仅 是 一 个 范围 扫描 ， 该 范围 扫描 的 结果 集 远 大 
于 STATE=0 的 过 滤 结 果 , 因此 在 这 种 情况 下 , 我 们 认为 针对 本 SQL, STATE 字段 的 选择 性 优 于 
SERV_ID 字段 。 

在 进行 这 类 分 析 时 ， 如 果 SQL 中 存在 绑 定 变量 会 让 我 们 很 头痛 ， 不 过 10g 版 本 的 
dbms_xplan.display 函数 提供 了 一 个 渠道 ,可 以 帮助 我 们 查看 SQL 进行 绑 定 窥探 时 的 绑 定 变量 值 ， 
有 了 这 个 工具 ， 在 分 析 SQL 时 就 不 必 担 心 绑 定 变量 了 。 

另外 要 说 明 的 是 , 本 案例 最 终 选 择 的 添加 索引 的 方法 并 不 是 最 佳 的 解决 方案 , 但 是 在 某 些 优 
化 场景 下 ， 最 好 的 方案 不 一 定 是 效果 最 佳 的 方案 。 这 正 是 优化 的 魅力 所 在 。 


19.2 一 个 查找 IP 所 属 区 域 的 SQL 优化 思路 


前 段 时 间 ， 和 QQ 群 里 的 一 位 朋友 讨论 了 根据 ТР 地 址 查找 其 所 属 区 域 的 SQL 语句 。 针 对 一 
个 耳 地 址 ， 如 何 才 能 找到 其 所 属 区 域 呢 ? 了 地 址 区 域 表 内 包含 区 域 编 码 、 卫 地 址 起 始 和 耳 地 址 
终止 3 个 关键 字段 。 由 于 一 个 全 地 址 只 能 对 应 一 个 区 域 , 所 以 这 种 查询 返回 的 记录 数 为 1 或 者 0 
(0 表示 未 找到 该 全 地 址 的 区 域 )。 

比如 , IP 地 址 表 主 要 的 3 个 字段 是 地 区 编码 ANO, IP 起 始 BNO F IPIE СМО. 查找 ANO 
的 SQL 语句 如 下 : 

SELECT ANO FROM TM1 WHERE BNO«z:IP AND CNO>=:1 В; 

为 了 找到 一 种 比较 好 的 解决 方案 ， 首 先 创建 一 个 测试 表 。 
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drop table tml; 

create table tml (ano integer,bno varchar2(20),cno varchar2(20)); 
drop index idx_tml; 

create index idx_tml on tm(bno ,CNO); 

declare 

va integer; 

vb varchar2(100) 

vc varchar2(100); 


begin 

và: =0; 

for i in 1..300000 loop 
va: =үа +1; 


select to char(va,'099999999999') into vb from dual 
select to char(va*s100,'099999999999'] into vc from dual 
insert into tml values(i,trim(vb),trim(vc)) 


va: zva4100 
end loop; 
commit; 
end; 


l 
这 样 , 我 们 就 创建 了 一 个 具有 30 万 条 记录 的 测试 表 ( 实际 环境 中 , 可 能 存在 上 千 万 条 记录 )。 
接 下 来 ， 我 们 来 看 看 如 下 语句 。 


select /*+ index(tml idx tml) */ ano from tml where bno<='000000000015' and 
cno>='000000000015' 
Execution Plan 
0 SELECT STATEMENT Opti mizer=CHOOSE (Cost=3 Card=313 Bytes=11581) 
1 0 TABLE ACCESS (BY INDEX ROW D) OF 'TM1' (Cost=3 Card=313 Bytes=11581) 
2 1 INDEX (RANGE SCAN) OF 'IDX_TM1' (NON-UNI QUE) (Cost=2 Card=56) 


Statistics 
0 recursive calls 
0 db block gets 
5 consistent gets 
0 physical reads 
0 redo size 
398 bytes sent via SQL*Net to client 
503 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
1 rows processed 


HB, consistent gets 是 5， 看 来 性 能 还 不 错 ， 接 下 来 ， 换 个 参数 试 试 ， 找 一 个 比较 大 的 值 来 
测试 。 
Statistics 


0 recursive calls 
0 db block gets 
62 consistent gets 
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0 physical reads 
0 redo size 
399 bytes sent via SQL*Net to client 
503 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
1 rows processed 


我 们 看 到 ,执行 开销 中 一 致 读 的 数量 变 大 了 ,实际 上 ， 随 着 参数 值 的 增加 ， 一致 读 的 数量 也 
会 增加 。 


select /*+ index(tml idx_tml) */ ano from tml where bno<='000030299900' and 
cno>=' 000030299900' 
Statistics 
0 recursive calls 
0 db block gets 
3195 consistent gets 
0 physical reads 
0 redo size 
398 bytes sent via SQL*Net to client 
503 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
1 rows processed 


这 是 什么 原因 呢 ?” 先 来 看 看 这 条 SQL 语句 的 WHERE 条 件 , 由 于 WHERE 条件 中 使 用 了 >=、 
<= 这 样 的 操作 ， 因 此 对 于 这 条 SQL 来 说 ， 需 要 进行 索引 的 范围 扫描 。 范 围 扫 描 会 从 第 一 个 符合 
bno<='000030299900' 条 件 的 索引 项 开始 扫描 索引 , 然后 根据 спо 的 值 判断 这 个 索引 项 是 否 满足 条 
件 ， 如 果 不 满足 就 继续 沿 着 叶 节 点 链 向 后 搜索 。 因 此 IP 参数 的 值 越 大 ， 扫 描 的 索引 叶 节点 数量 
就 越 多 ， 相 应 地 ， 一 致 读 的 数量 也 就 越 多 。 

实际 上 ， 在 这 个 业务 中 ， 最 多 只 存在 一 条 符合 条 件 的 记录 ， 而 且 ВМО, СМО 描述 的 区 域 是 
不 重合 的 ， 因 为 符合 bno<=:v 条 件 的 最 大 BNO 值 的 记录 才 有 可 能 满足 cno>=v 条 件 。 因 此 ， 如 
果 顺 着 索引 ， 按 照 BNO 字段 的 值 从 大 到 小 进行 扫描 ， 扫 描 到 的 第 一 条 符合 BNO<=:V 条 件 的 记 
录 ， 如 果 也 能 同时 满足 CNO>=:V 条 件 ， 就 说 明 已 经 找到 了 记录 ; 但 如 果 这 条 记录 不 满足 条 件 ， 
那么 在 这 张 表 中 就 找 不 到 合适 的 记录 了 ， 最 终 的 返回 记录 数 为 0。 

我 们 可 以 按照 以 下 方式 调整 索引 。 


drop index idx tml; 
create index idx tml on tml(bno desc,cno asc); 


根据 语义 修改 SQL, Jl ROWNUM«-I 的 条 件 。 


select /*+ index(tml idx_tml) */ ano from tml where bno<='000030299900' and 
cno>='000030299900' апа гомпит<=1 
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Statistics 
0 recursive calls 
0 db block gets 
4 consistent gets 
0 physical reads 
0 redo size 
398 bytes sent via SQL*Net to client 
503 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
1 rows processed 


调整 后 的 语句 如 下 : 


select /*+ index(tml idx tml) * ano from tml where bno<='000000546815' and 
cno>='000000546815' and rownum<=1 
Statistics 
0 recursive calls 
0 db block gets 
4 consistent gets 
0 physical reads 
0 redo size 
399 bytes sent via SQL*Net to client 
503 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
1 rows processed 
select /*+ index(tml idx tml) */ ano from tml where bno<='000000000015' and 
cno>='000000000015' and rownum<=1 


Statistics 
0 recursive calls 
0 db block gets 
4 consistent gets 
0 physical reads 
0 redo size 
398 bytes sent via SQL*Net to client 
503 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
1 rows processed 


可 以 看 出 ， 开 销 明 显 下 降 了 。 当 然 ， 对 于 没有 找到 记录 的 参数 ， 其 开销 是 不 会 变化 的 ， 因 为 
要 对 索引 进行 全 扫描 : 


select /*+ index(tml idx tml) */ ano from tml where bno<='900000000015' and 
cno>='900000000015' and rownum<=1; N 
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Statistics 


0 recursive calls 
0 db block gets 
3263 consistent gets 
0 physical reads 
0 redo size 
243 bytes sent via SQL*Net to client 
372 bytes received via SQL*Net from client 
1 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
0 rows processed 


如 果 要 对 这 种 情况 做 进一步 的 优化 ， 实 际 上 只 需 找到 第 一 条 符合 BNO>=:V 条 件 的 记录 ， 取 
出 其 CNO FI ANO, 然后 判断 СМО 是 否 满足 条 件 ， 如 果 满 足 就 返回 ANO， 否 则 返回 0。 这 样 对 
于 没有 找到 数据 的 情况 ， 也 可 以 达到 最 优 的 效果 。 

实际 上 ， 这 个 案例 是 根据 索引 扫描 的 特点 ， 以 及 IP 地 址 归属 地 查询 中 地 址 区 域 唯一 性 的 业 
务 规则 来 进行 的 。 因此 , 在 进行 SQL 优化 时 , 仅仅 依靠 数据 库 技术 是 不 够 的 , 我 们 还 必须 在 SQL 
中 充分 体现 出 业务 的 特点 ， 这 样 可 能 才能 达到 最 好 的 效果 。 


结 Жж 语 


这 本 书 是 伴随 着 痛苦 和 快乐 完成 的 。 快 乐 是 因为 我 又 可 以 和 大 家 一 起 共享 知识 和 经 验 了 。 其 
L, 整个 写作 过 程 也 是 我 对 知识 的 梳理 过 程 ， 通 过 写作 , 我 整理 了 自己 处 理 过 的 上 百 个 案例 ,并 
从 中 挑选 了 几 十 个 案例 ， 与 大 家 分 享 。 
痛苦 是 因为 这 两 年 是 我 们 最 忙 的 时 期 , 而 年 过 四 名 的 我 已 经 没有 了 当年 的 那 种 激情 。 忙碌 了 
一 天 之 后 ， 回 到 家 甚至 连 电脑 都 不 愿意 打开 。 而 几 年 前 出 版 的 《Oracle 优化 日 记 》 和 《ORACLE 
RAC Hid), 基本 上 都 是 每 天 晚上 一 边 在 QQ 群 里 和 大 家 聊天 ， 一 边 完 成 的 。 在 这 里 ， 要 特别 感 
谢 本 书 的 编辑 王 军 花 女 士 ， 如 果 不 是 她 一 遍 又 一 遍地 催促 ,这 本 书 不 知道 会 写 到 猴 年 马 月 了 。 另 
外 ,， 老 储 的 加 入 让 我 轻松 不 少 ， 最 费 神 的 几 个 章节 都 交 给 他 了 ， 他 对 数据 块 和 ASM 结构 的 了 解 
远 在 我 之 上 ， 所 以 这 些 INTERNAL 的 解密 交 给 他 也 算是 众望 所 归 了 。 这 部 分 内 容 的 详细 程度 让 
我 都 感到 有 些 吃 惊 ,解密 做 得 如 此 彻底 ， 看 过 这 两 节 的 内 容 ， 有 心 编写 DUL 的 朋友 可 能 又 会 春 
ВК) T o 

老 白 在 这 本 书 中 想 要 探讨 的 主要 内 容 其 实 不 是 技术 ,也 不 是 方法 ,而 是 一 种 理念 : 唯 有 理解 
了 Oracle 的 本 质 , 用 Oracle 的 思维 去 考虑 问题 , 才 是 DBA 奋斗 的 目标 。 只 有 Thinking in Oracle, 
才能 在 各 种 复杂 的 环境 中 找到 问题 的 关键 , 并 用 正确 的 方法 去 解决 问题 。 一 切 雕 虫 小 技 在 这 种 境 
MAAT, ALARA HD) AES A o 

其 实 想 做 到 Thinking in Oracle 并 不 困难 ,只 要 用 心 去 做 每 一 件 事 , 每 个 案例 做 完 后 都 认真 地 
总 结 一 下 ， 体 会 其 中 的 Oracle 本 质 ， 那 么 也 许 三 五 年 ， 也 许 十 年 ， 你 终归 会 达到 高 手 的 境界 。 
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数据 库 的 性 能 优化 一 直 是 DBA 日 常 工作 中 非常 重要 
的 组 成 部 分 ， 然 而 很 多 DBA 在 学 习 了 大 量 技术 ， 参 加 了 
大 量 培 训 后 ,仍然 会 在 实际 工作 中 遇 到 难以 下 手 的 问题 。 
实际 上 ， 在 数据 库 优 化 工作 中 ， 方 法 和 思路 远 比 技术 实 


现 重 要 得 多 。 


本 书 重 在 介绍 Oracle 数 据 库 的 性 能 调 优 方法 及 相应 0 
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的 工作 思路 ， 但 并 不 拘泥 于 技术 细节 。 作 者 通过 大 量 真 

案例 ， 深 度 剖 析 了 相关 技术 原理 ， 同 时 还 曾 述 了 理论 
知识 在 实践 中 的 应 用 方法 。 优 化 工作 的 本 质 其 实 就 是 透 
过 表象 探寻 根源 ， 解 决 问题 实现 调 优 ， 正 所 谓 “ 思 路 是 


道 ， 操 作 方 法 是 技 ”， 得 道 是 极 大 的 提升 ， 也 是 DBA 的 


思想 精髓 。 
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图 灵 社 区 引进 出 版 的 外 文 图 书 ， 都 将 在 立项 后 马上 在 
社区 公布 。 如 果 你 有 意 翻译 哪 本 图 书 ， 欢 迎 你 来 社区 

请 。 只 要 你 通过 试 译 的 考验 ， 即 可 签约 成 为 图 灵 的 


译 者 。 当 然 ， 要 想 成 功 地 完成 一 本 书 的 翻译 工作 ， 是 
需要 有 坚强 的 角力 的 。 


